So, you’ve just spent a few hours, days, or maybe weeks(!) tracking that down that bug. You’ve finally found it – what do you do? The fix is trivial, its a one line change, you can fix it right now, have it committed to source control, picked up in the next software release and move on to reading slashdot.

But before you go ahead and change that line of code, there are a few questions you should be asking yourself:

#1 How hard was it to track this bug down?

If you’ve been crawling over broken glass for a couple of days the chances are you’ve been adding some extra diagnostics to the system – these should be committed as part of the bug fix. Do not underestimate the importance of an easily diagnosable system, it will save you lots of time in the long run, not just for bug fixing, but during general development as well.

#2 Can I prevent the bug from being reintroduced in the future?

Now you can reproduce the bug (you have reproduced it before your claiming its fixed right?) – you need to write some form of test, why?

• The tests will first expose the bug, then prove the fix.
• The test will act as an insurance policy on your fix, as long as no one removes the test, the bug will stay fixed.

Ideally you’ll expose this via a unit test. This is the quickest form of feedback a developer can be given about the state of the system and will allow you to develop the fix with a very short feedback loop. If this is not possible,  then a regression test is your next best bet.

#3 Have I had it code reviewed?

A code review need only take a few minutes of another developers time, and will double the number of people that inspect the code before you commit, not a bad return really. If the code review takes longer, then the changes must be significant, or the problem domain suitable complex that running the change by another devloper really is a no brainer.

#4 Do I have a bug number to commit the change against?

Be sure to reference the bug number when you commit your fix. You don’t need to detail the symptoms of the bug in the commit, that is what a bug tracking system is for. Not only will this prove useful to other devlopers when they see your changes go in, it will also allow those that raised the bug see that work is happening on it.

Conclusion

These are the questions I go through in my mind before committing a fix – let me know yours!