Eric Sink wrote last year

The six billion people of the world can be divided into two groups:

1. People who know why every good software company ships products with known bugs.
2. People who don’t.

He went on to say, rather tongue in cheek

The surprising truth is that a person in group 2 can lead a productive life. In fact, as with most any other kind of ignorance, they’re probably happier that way.

So what is a bug? How do you know if something that is reported as a bug really is a bug? I have a simple definition for a bug.

A bug is any unresolved item in the bug database.

That makes it pretty easy. If it is in the database and isn’t resolved, then it is a bug. If it isn’t in the bug database then it isn’t a bug. Or if it is in the database but resolved, then it isn’t a bug.

But in order for this system to work there are a couple of caveats. First you need to make sure that everything, and I mean everything that could possible be a bug gets entered. What sort of things am I talking about?

• A client rings up with a problem with your application. It may not sound like a bug to you but that does’t matter, put it in the database.
• You are developing an application and some new code causes unexpected results in some other part of the application. Enter it in the database.
• You are fortunate enough, big enough to have onsite testers. Anything they find which does not work as expected goes in the database.

So you may end up with a lot of bugs. There is one more rule.

Do not start any new work until the bug count is zero.

Now that is going to take all the fun out of developing software, isn’t it? Not really. I didn’t say you had to fix every bug. Remember, a bug is an unresolved item in the bug database. All you have to do is resolve every item.

There are a number of ways to resolve a bug. The obvious way is to fix it. But this is not always the best way. Time for a story.

A client rang me with a report of a bug. I entered in the bug database, and set about trying to resolve it, or at least try to determine the best way to resolve it. Unfortunately, I couldn’t replicate it. So, as far as I was concerned the resolution for this bug was marked as Could not replicate, and the bug was closed. I rang the client back and told them I couldn’t replicate the problem, she had a look and said it seemed to be OK on her machine as well, and so all was well.

Within the hour she rang back and said that the bug had returned. In the bug database I set the resolution to Under Investigation and at the first opportunity I visited the client. She showed me the bug. This was not technically a bug. The application was behaving exactly as the specs provided, but, under certain circumstances it was not what the client expected. In this case there was an easy work around. There was also an easy fix, so what did I do? I did not fix the bug. If it was an easy fix, why not? Because every new bit of code is a potential source of new bugs. But it was a desirable fix, so the resolution in the bug database is for it to be reviewed as a feature in the next version. That way it will be looked at properly. The problem with an easy fix is that it can viewed as a quick fix, which can easily become a quick and dirty fix.

The point is that the client reported behaviour which was not expected. Therefore it gets entered into the bug database. Then it must be resolved. In this case the resolution was for it to be fixed in a future version.

Some bugs will never get fixed. Their severity and frequency is so low that it isn’t worth the risk.

Other bugs demand immediate fixing because they are very severe, and occur very often.

But all bugs demand resolution.