{"id":6,"date":"2009-10-07T22:49:00","date_gmt":"2009-10-08T05:49:00","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=6"},"modified":"2010-03-31T10:46:06","modified_gmt":"2010-03-31T17:46:06","slug":"why-bugs-dont-get-fixed","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/why-bugs-dont-get-fixed\/","title":{"rendered":"Why bugs don’t get fixed"},"content":{"rendered":"

I\u2019ve run into more and more people lately who are astounded that software ships with known bugs. I\u2019m frightened that many of these people are software testers and should know better. First, read this \u201cold\u201d (but good) article<\/a> from Eric Sink. I doubt I have much to add, but I\u2019ll try.<\/p>\n

Many bugs aren\u2019t worth fixing. \u201cWhat kind of tester are you\u201d, I can hear you shout, \u201cTesters are the champions of quality for the customer!\u201d I\u2019ll repeat myself again (redundantly if I need to \u2026) Many bugs aren\u2019t worth fixing<\/strong>. I\u2019ll tell you why. To fix most bugs, you need to change code. Changing code requires both resources (time), and it introduces risk. It sucks, but it\u2019s true. Sometimes, the risk and investment just aren\u2019t worth it, so bugs don\u2019t get fixed.<\/p>\n

The decision to fix or not to fix isn\u2019t (or shouldn\u2019t be) entirely hunch based. I like using the concept of user pain<\/em> to help make this decision. There are 3 key factors I consider to determine user pain. These are:<\/p>\n

    \n
  1. Severity<\/strong> \u2013 what\u2019s the impact of the bug \u2013 does it crash the program? Does the customer lose data? Or is it less severe? Is there an easy workaround? Is it just a cosmetic issue?<\/li>\n
  2. Frequency<\/strong> \u2013 how often will users hit this issue? Is it part of the main flow of the program, or is the issue hidden in an obscure feature. Minor issues in mainline scenarios may need to be fixed, but ugly stuff in an obscure feature may slide.<\/li>\n
  3. Customers Impacted<\/strong> \u2013 if you\u2019ve done your work up front, you have an idea of who your customers are, and an idea of how many users are in (or how many you would like to be in) each of your customer segments. From there, you need to determine if the issue will be hit by every user, or just a subset. If you have the ability to track how customers are using your product you can get more accurate data here.<\/li>\n<\/ol>\n

    From here, make up a formula. Assign a value scale to each of the above and apply some math \u2013 you can do straight addition, multiplication, or add weights based on your application and market. For our purposes, let\u2019s just add and use a 10 pt scale for each bug :}.<\/p>\n

    Bug #1, for example, is a crashing bug (10pts) in a mainline scenario (10pts) impacting 80% of the customer segment (8pts). At 28pts on the user pain scale, I bet we\u2019re going to fix this one.<\/p>\n

    Bug #2 is an alignment issue (2pts) in secondary window (2pts) in an area used by a few \u201clegacy\u201d users (2pts). At 6 pts, this is a likely candidate to not get fixed.<\/p>\n

    Unfortunately, they\u2019re not all that easy. Bug #3 is a data loss bug (10pts). It occurs in one of the main parts of the application, but only under certain circumstances (5pts) (btw \u2013 numbers are completely made up and subjective). Customer research shows that it\u2019s hardly ever used (2pts). At 17 pts, this one could go either way. On one hand, it\u2019s probably not worth the investment to fix. As long as the issue is understood, and there are no blind spots, leaving the bug in place is probably the right thing to do.<\/p>\n

    On the other hand, you have to weigh this with the rest of the bugs in the system. The Broken Window<\/a> theory applies here \u2013 if there are too many of these medium threshold bugs in the app, quality (or at the very least, the perception of quality) will suffer. You need to consider every bug in the system in the context of the rest of the (known) bugs in the system and use this knowledge to figure out where the line is between what gets fixed and what doesn\u2019t get fixed.<\/p>\n

    It sucks that the industry ships software with known bugs \u2013 but given the development tools and languages we have today, there isn\u2019t a sensible alternative.<\/p>\n

    Edit:<\/em><\/p>\n

    As this sits in my head, I think I’ve missed a fourth factor in the forumla: Ship Date. The proximity of ship date plays into the fix\/don’t fix decison as much as the above. I’m not sure, however, whether it’s a fourth factor in the math, or if the threshold of what “value” of user pain turns into a bug fix as ship dates approach.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

    I\u2019ve run into more and more people lately who are astounded that software ships with known bugs. I\u2019m frightened that many of these people are software testers and should know better. First, read this \u201cold\u201d (but good) article from Eric Sink. I doubt I have much to add, but I\u2019ll try. Many bugs aren\u2019t worth…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-6","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}