My Theory of Bug Classification

Givens

1. 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.
2. 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.)
3. 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 internal stakeholders or external customers).

Theory

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

• "Success", Client asked for X and got X: New feature or fixed bug, properly implemented.
• "Miscommunication", Client asked for X and got Y: Communication failure, dev and client had two different ideas about what was being requested and why. 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. (Technically this is a sub-type of Miscommunication.)
• "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.

Avoiding the introduction of bugs is the process of communicating and verifying intent. For clients, this means healthy reviews of changes to mitigate Miscommunication< items. For devs, this means both testing at whatever levels are necessary to ensure Regressions do not occur, and doing their best to understand requests accurately for their end of Miscommunication.

Note that there is no categorization for "developer introduced an uncaught syntax error or runtime error in the code." While this can certainly happen, this is an observation issue. Until it is detected and reported, it doesn’t count as a bug. Once it is, it’s a regression.

Others that seem different but are actually examples from above:

• I asked for X but really need Y and got X (or Y): Client’s understanding of their own need is incorrect, developer may or may not "know better." This is just X -> Y.
• X has never worked right: Still just X -> Y.

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?