June 28, 2006

Being Happy About Bugs

Bugs are embarassing. I hate producing them. (Not that I ever have, but let's just talk hypothetically here.) But I like bug reports. Not the type of "bug" report produced by the user who thinks that everything he doesn't like is automatically a bug. That gets into a gray area. What I'm talking about today is the real, verifiable, squirming bug.

OK, so I've cheated a little on the title of today's post. It's not the existence of the bug that is a happy event, but rather the fact that it was found and reported. A bug report represents an opportunity to make our product better. So I try to be happy about receiving bug reports.

Now, we would hope that there are no bugs to be found. It's our responsibility to ensure that they don't exist. The only bugs that should ever be reported to a developer are the type that highlight a misunderstanding of the requirements, a change in the requirements, an unanticipated side effect, a breakdown in communication, or some other issue external to the coding unit that we created and tested. (Note that I'm not really talking about "specs" here. Don't tell anyone, but specs are almost always wrong. I'm thinking more about the real requirements, which are a combination of the written requirements document and the real needs of the users.)

Even reports of things that aren't really bugs can be valuable to us. Maybe the user didn't understand something about our product, and we can improve the user interface or training. Maybe the report doesn't describe a real bug but points out an area that we could enhance.

I've worked with many people who treat bug reports with hostility or fear. Their first objective is to find a reason that they are not to blame. This can be done by finding a scapegoat, criticizing the requirement, attacking the messenger, or via various other methods. This is damaging to morale and is usually a waste of valuable time that can better be used in fixing the bug. Controlling scope is a good goal, but how many times have we all spent in interminable meetings to discuss things that could be coded in a few minutes?

Nobody really likes bugs. When one is found, we should try to determine whether it was our own oversight (and we should do better), or whether it was caused by some other issue. But this is no substitute for fixing the bug. We should try to be happy that the bug was found—the earlier the better—and approach the whole issue with a positive attitude. In fixing the bug we will learn and will improve the product. And consider the alternative—a bug that isn't found until it becomes a major problem.

Until next time...