Bugfixing: Easy Wins vs Risky Fixes first

We are entering the final stage within my current project: testing and bug fixing.

Now we have bugs coming in on a steady stream, but I started wondering how to choose the best bugs to start with. After some pondering, I came up with following:

There are 2 special kinds of bugs, the easy wins and the investment bugs.

Easy wins are bugs (small or large doesn’t matter) that are relative easy to fix. I didn’t say fast, since if it contains a large portion of the program, it could be taking more time then a more difficult bug. Instead it’s just something you know how to fix, like fixing a typo. You’ll spot an easy win when you see one.

Risky fixes are the pain. You need to make a critical adjustment before fixing the bug. Worse even, if you can’t guarantee for sure that no new bugs are introduced. It could be fixed fast, but may involve a hack. A good example is when you have done something a hundred times in one way, but then the 101st time something has to be done just a little different, and you need to change the code a little…

Anyway, now came the more important question: Do I fix the easy wins first, or go first for the risky fixes?

Fixing the hard ones first, seems like the most obvious choice. Start with the hardest, work your way down. Going a little bit further, you know that you might introduce new problems. In fact, you might introduce a new bug (feature!) into an already broken part. Tricky to fix, 2 bugs at one time… As always, but especially with the risky fixes, time needs to be invested to get to the best possible fix. So bug fixing is slow when starting with these ones first.

So, going for the easy win looked like a great way then? Well, it sure gets the bug fixing up & running. One bug after an other gets tackled, leaving only a handful for the last period! But the last ones are going to introduce new ones, right? Actually we are giving a wrong image, the amount of bugs reported and not fixed might seem low, but the work behind them is still large.

I finally decided to go for the risky fixes first, for the following reason: when introducing new bugs by doing the risky fixes, the chance that those bugs are spotted is larger because

• The time spend testing is larger since the bugs are fixed at the beginning of the test phase,
• the other bugs need to be fixed as well, which might expose new bugs (not create) when fixing an easy win bug.

Last but not least, I’d like to close with a final thought. I don’t like it when 2 of my developers are doing a risky fix on nearby code. When one of the two go wrong, it’s a little harder to spot which of the 2 caused the problem. I like to mix and match, letting the risky ones go first 1 at a time, filling the rest with easy wins. Luckily, the easy wins outnumber the risky fixes!