We have a natural desire to fix things. As engineers we find satisfaction in resolving technical problems and, if you’re following test-driven practices, keeping them resolved. These thoughts flow through our minds as the primitive keyboard-wielding code monkeys we evolved from. What distinguishes us from our fecal-flinging counterparts, however, is our ability to question these instincts and wear business, user and developer hats simultaneously. Here are some additional questions we should consider before immediately reacting with technobabble.
- What business value could be realized by addressing this issue? It would be ideal to resolve it, yes, but is there any ROI for the time spent?
- How risky is this? If cleaning the big red button could potentially fire the nuke, you might want to leave the booger on it.
- How critical is this issue? If sufficient workarounds exist or this does not prevent people from working, perhaps you could move it below other todo list items that are.
- How does this make users feel? Requiring the user to click OK every two minutes will create desire to stab you with a sharp object. Your death will generate bad vibes around the project.
- What is the business impact? If the tree fell, but nobody lives in the woods.. what tree?
- What are the dependencies and dependants? Superman requires his tights be dry-cleaned before saving the planet today. You might want to run to the dry-cleaners.
- When could a resolution actually be delivered? It may take 2 minutes to fix, but if users can’t get it for two months perhaps the work can be postponed.
- Who is be most appropriate person to handle it? Maybe it’s you. Maybe it’s the guy who actually wrote the code.
- What actually needs to be fixed? Don’t replace the alternator if you only need a battery.
- Where does this fall in the project timeline? If the next deliverable is already late, you might need to rescope by sitting down with the business and reevaluating what is truly necessary.
2 replies on “..But *Should* You Fix That Bug?”
“As engineers we find satisfaction in resolving technical problems and, if you’re following test-driven practices, keeping them resolved.”
Does that mean that people who don’t follow test-driven practices don’t like keeping problems resolved? Haskell programmers, for instance, often use the static type system to eliminate potential problems. Of course, it’s arguable that static typing is test driven, but I doubt that’s what you mean.
I’d say “don’t worry, just fix it” in general. If your testing and code review procedures are good enough, it’ll be ok. Only if you don’t use source control are you in any danger in most projects.
Everyone likes keeping problems resolved, so now that you know what broke, how about adding a case to your regression suite to ensure that it stays fixed in the future? Even with robust revision controls systems, mistakes happen during checkins, merges, and future updates to the code that may undo your hard effort unbeknownst to you. A unit test provides a proactive way of ensuring the issue stays fixed.