/dev/etc 18 Apr 2007 12:59 am
Don’t Fix Symptoms
Here is a bug:
BUG: When the user presses the jump button while they are in the Cave of Sorrow their character will cast a Fire spell and will not jump.
Fixing this bug seems easy! Why, open up levels/caveofsorrow.cpp and just make it so the player’s character jumps instead of shooting fireballs when they press the jump button. Well, that’s easy, let’s do that. Awesome, now the user jumps when the user presses the jump button. Bug fixed! Let’s go home!
The next day, your neighbor gets this bug:
BUG: When the user presses the jump button while they are in the Hall of Power their character will cast an Ice spell and will not jump.
So he opens up levels/hallofpower.cpp and, as you had done before, he makes it so that the player character jumps instead of casting an Ice spell.
BUG: When the user presses the jump button while they are in the Mountain Cave of Halls their character will cast an Air spell and will not jump.
This bug goes to yet another programmer, and they fix it the same way. Three days have passed in this completely fabricated example. These programmers are incorrectly treating symptoms of bugs but none of them are fixing the actual bugs, which are likely in either the jumping code or the spell casting code. I’ve seen this sort of thing happen in web development, game development, and application development (and hell, when people are tired of fixing hard bugs, they’ll probably sit around and try and fix the “low hanging fruit” that seems easy enough to fix). The problem with this method of fixing bugs is that after enough people fix this symptom in enough places, your code ends up covered in special case work arounds to some core problem that could be fixed in half the time. Sometimes you just have to suck it up and fix the big problems!
One thing I like to do for this is to have the experienced guys on a team get together daily or even several times a day to try and find bugs that fit into buckets (I prefer classifications, but hey, buckets are fun, too). These buckets should be pretty precise (and a bug can be in multiple buckets!), but they should make it easier to dish out the work or to figure out when a class of bugs are actually a result of a bug in the requirements (either those from the client or the technical designers). If you don’t do this, your code will probably suck the next time you look at it, as there will be bandaids on top of bandaids on top of bandaids when the actual cuts and bruises won’t heal.
