4 Things To Consider When Fixing a Bug

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!

7 Comments

  1. Similar to #2, but deeper: *why* did this bug occur in the first place, and can I stop *similar* bugs from ever occurring in future?

    For example, is there an API which is hard to use correctly and needs to be avoided/wrapped/changed? In a web app, I shouldn’t really be fixing SQL injection or XSS, I should be designing my system so that by default they are impossible.

    Or if it is a logic bug, and I wrote it, does it belong to a class of things I routinely get wrong e.g. out-by-one errors? If so, how can I fix the way I think so it doesn’t happen again?

  2. You missed the most important point to consider when dealing with badly written systems and BEFORE fixing the bug.

    Is anything else dependent on the bug?

  3. Disagree somewhat substantially with point 1: hard to track down bugs are usually in legacy and/or complicated code, where understanding of invariants is woolly or lost in mists of time and staff turnover. Writing good diagnostics beyond basic logging is not easy, precisely because your knowledge of the invariants are woolly. Sometimes the only way to get good diagnostics is to rewrite the thing, and if it’s too complicated, that may not be a good value proposition for the business; so you just have to live with it, and fix other issues when and if they come up.

    Disagree slightly with point 4: do mention what the bug is, a one-liner description of the symptom or cause of the bug. This helps hugely in reviewing change logs looking for breaking changes in a team environment – a bug number or other cross-reference means you have to open up a separate data silo and hugely slows down what should be 3-second a visual scan.

  4. #5 Know the history. Use the version control system to determine when the bug was introduced. Was the bug created as a result of trying to fix something else? Has it been in there a really long time? If the bug has been in there for a long time and didn’t manifest…what changed? This is one of the main reasons why when you check-in code changes that are associated to a bug or enhancement in your tracking system, that you record the tracking system number in the check-in notes.

    Additionally, I would recommend that folks use good judgment on #1. While in the general cases what you suggest is just fine and for valid reasons…if the code is in a section that needs high performance…too many checks will degrade your application’s performance and could cause problems from a customer perspective and in some cases may impact SLAs.

  5. Is it really a bug?

    It may very well be a *feature* that many users (inside and outside the team) are dependent on. e.g. SHStripMneumonic is misspelled.

Leave a Reply

Your email address will not be published.