| Being Happy About Bugs | KEVIN RESCHENBERG
06-28-2006 |
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.
|
