Defining a "bug" part 3

It is review time here at Microsoft and I already heard the phrase "I do not think I opened enough bugs last year.  What do you think?"  I typically give the answer "Well, how much homeowners insurance do you have?" which seems odd (and is) so I want to clarify what I mean here.

First, in this context, "bug" is being completely misunderstood.  I talked about it before, but in this context, the tester is talking about an entry in our bug tracking database rather than a bug found (and fixed) in code review or the design phase.  We typically do not deal with the overhead of using the database for those types of bugs - just mention it in a face to face meeting, write it down and fix it.  Those never get included in what most people perceive as a "bug count."

To address my insurance analogy, you need to consider your tasking for the year to help figure out how well you did.  If you were testing a new area of the product, you may find more bugs than someone who was testing a legacy feature.  Likewise, if you spent most of the year writing tools, you probably had little time to find and enter bugs so expectations there are adjusted downward.  This is the same situation with homeowners insurance.  If you do not own a home, you do not need this insurance.

"Bug count" as a metric has always been easy to track, but never made much sense to me as a standalone value.  There are simply too many outside factors that need to be accounted for to make this statistic have much meaning.  But since it is very easy to compute (just refresh a query against the db) is tends to have far more importance attached to it than should be.  And we have only mentioned quantity so far, not quality….

Questions, comments, concerns and criticisms always welcome,
John