Comments on: 4 Things To Consider When Fixing a Bug

By: Giorgio Sironi

Giorgio Sironi — Wed, 09 Sep 2009 21:32:30 +0000

Good checklist. I like the TDD way of thinking.

By: choy

choy — Wed, 09 Sep 2009 07:55:16 +0000

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.

By: Kim Greenlee

Kim Greenlee — Tue, 08 Sep 2009 04:08:47 +0000

#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.

By: Barry Kelly

Barry Kelly — Tue, 08 Sep 2009 04:00:23 +0000

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.

By: Null

Null — Tue, 08 Sep 2009 02:43:41 +0000

You forgot: What test cases are there to test your fix against?

By: mehblah

mehblah — Mon, 07 Sep 2009 21:56:13 +0000

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?

By: Luke Plant

Luke Plant — Mon, 07 Sep 2009 18:34:20 +0000

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?