If you've ever used software before then of course you've run into software bugs. Some are major, some are minor, and some are a real pain in the arse.

I've been thinking about them a bit recently while implementing a new issue tracking system at work for use for our product issue tracking. We've been moving from a free, fairly basic system, called DCL (Double Choco-Latte), to a much more flexible, commercial system called Jira. So far it seems really good, and makes things a lot easier to manage than DCL did.

But first of all, why do issue tracking? Sure us software people fix all bugs as soon as they get reported. And why would we release software with bugs in it in the first place - doesn't that mean we are just slack?

Well, as Eric Sink points out, people tend to be divided into two groups on this:

1) People who know that every good software company releases software with known bugs.
2) People who don't.

The reality is that there are a number of constraints as to why fixing every single bug is just not possible.

Firstly, there is the simple unfortunate truth that any code change is risky. Some are riskier than others, but whenever you change the code to fix one bug, there is a risk that the change will introduce another. And in some cases, the newly introduced bug is worse. Consequently fixing bugs when you are close to a release date is very risky, as the small amount of time left for testing means that there is a reasonable chance that it will slip through.

This brings us to the second problem. There is not an infinite amount of time available to develop a product. It needs to be released to the market at some stage, or someone else will release their competing product instead.

Furthermore, some bugs are simply not worth the effort to fix. They may be very minor, only occur very infrequently, but take a disproportionate amount of time to fix.

So we access bugs on several criteria. Firstly, how severe is it objectively. A small typo on one screen is very low, but a data corruption bug that affects all users is critical. Then we assess the business priority to fix it. This takes account of the severity, the frequency that it occurs, the risk and cost to fix them, and is relative to other bugs or features that we could be working on instead. The business priority is then used to determine which bugs are fixed.

This is simply because ultimately the purpose of our software development is to generate business value, and so the business priorities must drive what we work on.

So, we do release products with known bugs in them. But they are acceptable bugs, and more importantly, we have a good idea of the quality level of the product before it is shipped.

That is a much better than shipping a product where we tried to fix everything, but have an unknown quality level, and may have introduced other unacceptable bugs intead.

Posted by Dave Bryant at 7:47 PM | Comments (1) | TrackBacks (0)