Squash the Bug, Then Close the Window
September, 2007
I usually edit two pieces of code when I’m squashing a bug. First I fix the specific bug, and then I go on a hunt for ways to prevent similar bugs in the future.
Can I make the code fail faster?
Bugs that happen earlier in the execution path are easier to investigate.
If an invariant was destroyed, the sooner you detect it the better. It’s great if you can check for the invariant right after you modify the data. If you have complex invariants then you might consider adding a CheckInvariants() function that gets called periodically.
If the bug doesn’t throw an exception, can you test for it and throw an exception when the condition occurs? Exceptions codify error conditions. If you collect exception reports then you’ll know how popular a bug is, you can see patterns of occurrence, you’ll know for certain when it’s fixed, and so on.
Can I make the bug more apparent?
The worst bugs only appear if the user is running Japanese Windows and singing in the shower while holding the control key. As a programmer I don’t do that often so the bug won’t be caught until release. Bugs get exponentially more expensive the longer it takes to find them. You will fix bugs earlier if you can make them more apparent, and everybody wins.
This principle is true even at the small scale. There’s a product category just for apps that tell you when you broke the build one minute after it happened. [1] You get to fix it quickly, instead of getting the email from your annoyed coworker one hour later. There are real dollars there.
Can I make this bug easier to fix in the future?
You might be able to make the bug cheaper to fix if it reappears two months later. Add a comment block detailing how the bug happened and how you fixed it. Reference the bug’s ticket number. Modify the code to include more relevant info in the error report.
One of the things I hate about C# (and Java too?) is that you can’t get the locals of a stack frame. This feature would save us lots of time and money when deciphering error reports from the field.
Can I make the bug impossible?
Wow, wouldn’t it be great if you could do this for every bug?? We don’t use static code analysis at Xobni yet, but that’s something I’d love to change. It can catch so many simple problems. You hard coded a string instead of putting it in the internationalization string table. You write ‘if(x == null) x.Foo()’ instead of !=.
Can I make the bug more obvious to humans?
Great software design makes bugs obvious. Is there some refactoring I can do to make the bug scream at anyone who reads or writes it?
Bonus!
I also like to comment out all exceptions before shipping a release build. That way users never see any errors! [2]
Notes
[1] This idea is called continuous builds. We recently implemented continuous builds and we all have fewer headaches.
[2] (From the bad joke department.)