Trying to define "bug", part 1

One of our interns from last year and I had a chat last week in which we started to debate the definition of a "bug." This had started here within the OneNote hallway with the simple question of "If no one files a bug in our tracking tool, does the bug really exist?" The point of view I had at that point was fairly pragmatic and not philosophical. A better way to ask that question would be, "If I notice a bug in your code before you check in (let's say I came by your office and noticed some code on your screen) and you fix it before you check in, did a bug ever exist?"

From a tracking point of view, and from the viewpoint I was pursuing, a bug never "really" existed since there is no record of it in our tracking mechanism. This is all common sense at this point. A larger issue was whether or not we could ever go back and track what I saw in code review. A simple typo is largely irrelevant and at one point I thought we could live without that detail in our history. Something larger - maybe you were wanting to use a different API - might be more interesting since having a record of your decision would also allow us to review decisions made during feature development. That decision process may be interesting in the future and having it around might prove to be beneficial.

(Actually, we do have tools that record code coverage comments, but in my example, this is just something I informally noticed).

So we agreed in this case, a "bug" in the pure sense existed, but a "bug" as defined by the limitations imposed on us by our tools, did not exist.

Next up I will continue this conversation - we chatted for about an hour on this and covered a lot of ground.

Questions, comments, concerns and criticisms always welcome,

John