Squash the Bug, Then Close the Window
(This message was pre-recorded.)
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 joke department.)
October 23rd, 2007 at 9:50 am
The trouble with user who is running Japanese Windows and singing in the shower while holding the control key, is that this is how they use the software. Now, since the software isn’t working their first impression is that the software is buggy. They then have to contact support, and if this is a new issue support won’t have an answer for them right away. So there is strike two, and if the bug is claimed fixed and sent out to the customer without testing, something else could go wrong and there you have strike three.
It all starts and ends with the QA team, while they might not find everything, they are the superstars that try to find these things. In my case I have enough information and knowledge on programming and computers to understand where systems might fail. Up until recently I worked in the game industry, where knowing that 256 was a magic computer number served me well.