Nothing ventured, nothing gained

When I read Seth’s recent post on apologizing to customers, I couldn’t help but observe a similar approach one takes when dealing with software bugs.

There are many incorrect ways to handle a software bug, but only a few correct ones. If you’re blessed with tact, technical know how, and a burning desire to right the wrong, then you probably already knew this.

On a scale of 1 to 10, where 10 is the best approach

• “I didn’t do it.” (-1). Actually, you did. Last Friday at 1:42 PM. Honesty, and good source control, is the best policy.
• “It’s not my fault.” (1): It’s not personal, it’s bug triage. Your team is trying to determine what to fix, and who should fix it. No one is trying to assign blame.
• ”I’m not done with it yet, don’t use it.” (1): Fair enough, but if you checked it in, you should at least write a unit test to go along with it, even if it explicitly fail()’s. This way, we know it’s not suppose to work and nobody is caught by surprise. Type II errors, or false negatives, are a huge liability for a development team because the tests are believed to be verifying the intended behavior of the software.
• “It’s not my fault; the spec is wrong.” (2): Not a problem. Mention the behavior to a colleague or notify the team lead about the discrepancy. If two heads see a problem, then there’s probably a genuine problem. Don’t get too defensive about it and be careful not to start with “The spec is wrong…”
• “It’s not my fault the spec is wrong.” (1): What did I just say about getting defensive?
• “It’s not a bug, it’s a feature.” (3): Oh? Really?
• “Yes, it is a bug.” (5): Well, all right then, these things happen. What are you going to do to fix it?
• “Yes, it is a bug. Stop by in a few hours and I’ll either have a fix, or I’ll have an idea for a fix.” or “Yes, it’s a bug, but a fix is already in the works and should be in by tomorrow’s build.” (9): Brilliant and spot on. This is pretty much the response everyone wants to hear, but it doesn’t mention what actions you’ll take to prevent the bug, or similar bugs, from occurring in the future. The complete approach is:
• “Yes, it’s a bug. I have a fix. In addition, I also wrote a unit test that makes sure that bug, and bugs similar in nature, will never occur again. This way, we can prevent a whole class of bugs from occurring with one fell swoop. This is a good thing because life is too short to only use an approach for testing that relies solely on people’s ability to execute a series of mouse clicks and keystrokes when the processing power that makes computers so useful can be leveraged to execute these tests, freeing testers from especially mundane or repetitive testing so that their brains can be used for higher order tests that computers can’t do yet.” OK, so in truth, you probably won’t say something like this, but that shouldn’t stop you from doing it.