My Theory of Bug Classification

Givens

1. All software necessarily exists for the benefit of human users. Even compilers that programmers use are not required by the computer to function. The compiler exists solely to provide the human programmer with a representation of the program that’s easier to understand, reason about, and modify that strings of 0’s and 1’s. There is no software that doesn’t benefit a human somewhere, in some way. (This in itseslf is a big idea that is perhaps poorly appreciated by programmers at large, and worthy of a whole blog post.)
2. A “bug” by definition is only a measure of intention. Without intent, all programs operate exactly how they were programmed–nothing is an error or failure, because we don’t know if the programmer intended the observed operation or not. The operation can only be deemed “incorrect” compared to some external concept of how the program “should” behave.
3. All software “bugs” happen as a result of making changes to the code. Zero code has zero bugs. It’s possible for non-zero code to have zero bugs, but it might or might not be provable as such. Additionally, only those mismatches between actual program behavior and intended behavior that have been observed can be considered bugs, since an unobserved mismatch by definition has not affected any human user and remains entirely undiscovered. (Whether a user recognizes a mismatch between actual behavior and intended behavior is also another story.)
4. No program springs fully formed into existence all at once, so errors must be introduced by successive changes over time. Typically the changes are at the direct or indirect request of the client (which may be the programmer themselves, internal stakeholders or external customers).

Theory

The result of ALL changes to software can be classified into one of the following groups:

• “Success”, Client asked for X and got X: New feature or fixed bug, properly implemented, such that the observed behavior matches the intent.
• “Miscommunication”, Client asked for X and got Y: Communication failure; programmer and client had two different ideas about what was being requested and why. New behavior does not match intent. If not corrected, this becomes a “bug” and a future input for X.
  • “Incomplete”, Client asked for X and got x: Partial new feature or fixed bug, but not yet completed. If not corrected, this becomes a “bug” and a future input for X because again, new behavior does not (fully) match intent. Technically this is just a sub-type of Miscommunication, or a temporal variant resulting from comparing intent and behavior too soon.
• “Regression”, Client asked for X and got X, x or Y, but Q (existing) also broke: Regression, the changes for X had negative (side) effects. Code whose behavior previously satisfied the client’s intention no longer does so. If not corrected, this becomes a “bug” and a future input for X. Behavior previously matched intent and no longer does.

Implication

Avoiding the introduction of bugs is the process of communicating and verifying intent. For clients, this means healthy reviews of both proposed and completed changes to mitigate Miscommunication items. For programmers, this means both testing at whatever levels are necessary (manual, unit, integration, acceptance, a/b, etc) to ensure Regressions do not occur, and doing their best to understand requests accurately for their end of Miscommunication. The final factor is providing sufficient time before comparing behavior to intent.

Note that there is no categorization for “programmer introduced an uncaught syntax error or runtime error in the code.” While this can certainly happen, this is an observation issue. An attempt to implement the intent was made, but can’t be compared to behavior because the behavior was never exercised. Until any such syntax or uncaught exception or runtime error is detected and reported, it doesn’t count as a bug. Once it’s known, it’s a regression.

Variations

• I asked for X but really need Y and got X (or Y): Client’s understanding of their own need is incorrect so they expressed the wrong intent, programmer may or may not “know better,” and may or may not implement the request behavior and/or the intended behavior. This is just X -> Y. Intent was miscommunicated.
• X has never worked right: Still just X -> Y. Intent never fully made it from client to programmer to published code.

Challenge

Does anyone know of any existing written material on this?

• http://programmers.stackexchange.com/questions/37029/difference-between-defect-and-bug-in-testing?

Are there any missing classifications?

Can they be reduced further?