What does Orthogonal Defect Classification add over a free-text cause field on a defect record?

## The problem it solves Most defect trackers have a cause field, and most cause fields fill up with prose. Prose is excellent for one record and useless for four hundred: you cannot count it, you cannot compare this quarter to last, and every reader summarises it differently. The alternative that teams reach for first - a single closed list of causes - is better but coarse, because one dimension has to carry too much meaning at once. Orthogonal Defect Classification is the published response to that. Instead of one field, it records a small set of attributes, each drawn from a short fixed list, chosen so that the attributes are **independent of one another**. That independence is what "orthogonal" means here, and it is the whole design idea: one defect gets exactly one value on each attribute, values do not double count, and the resulting distributions can be added up. ## What gets recorded The exact attribute lists vary between adaptations, and any team adopting the scheme tailors them, so treat the following as the shape rather than as a fixed standard: * **Defect type** - the nature of the correction: an assignment, a check, an interface, a piece of function, an algorithm, and similar. Notably this describes the *fix*, not the symptom. * **Qualifier** - whether the thing was **missing**, **incorrect**, or **extraneous**. This one attribute carries a surprising amount of signal, because "we never wrote it" and "we wrote it wrongly" call for entirely different responses. * **Trigger** - the condition or activity that surfaced the defect: what the reviewer was checking for, or what kind of workload or sequence the test applied. In this scheme it is a classification attribute describing what exposed the defect, not a causal-analysis conclusion. * **Impact** - what the defect affected from the user's point of view. * Some adaptations also record where the affected artefact came from (written here, reused, supplied externally) and how old it is (new, changed, or long stable). Two of these are captured at the moment the defect is opened, when the finder knows what surfaced it and what it hurt; the rest are captured when it is closed, when the fixer knows what actually had to change. Splitting the capture that way is deliberate - it asks each person only what they are in a position to know. ## What it buys, and how it is read The output is a **distribution**, and the interesting readings are shape changes rather than absolute numbers: * Many **missing** qualifiers on function-type defects late in a cycle suggests requirements were still moving, not that coders were careless. * Many **incorrect** qualifiers on checking-type defects suggests the problem sits in implementation detail, where reviews and low-level cases pay off. * A trigger distribution dominated by one kind of condition suggests the other conditions were never applied, which is a statement about test design rather than about the software. Read against the phase in which each defect was found, those distributions are meant to be **in-process feedback**: the profile a team sees at a given phase can be compared with what that phase usually looks like, and a mismatch prompts a question while there is still time to act. ## How it relates to origin and escape Origin and escape are a two-field version of the same instinct: make the fields countable and make each answer a different question. A structured scheme extends that with a few more independent dimensions and, importantly, a *qualifier* dimension that origin alone does not carry. A defect with a requirement origin and a missing qualifier is an unwritten decision; a requirement origin with an incorrect qualifier is a decision that was made and made wrong. Both point at the specification process, but at different parts of it. ## The costs, and why adoption is patchy The scheme is not free. Every defect costs a little more to close. Values must be picked consistently or the distributions are noise, which means calibration sessions and a written tiebreak for the boundary cases - the same discipline any classification field needs, multiplied by the number of attributes. Teams that adopt a full scheme without that discipline usually end up with a tidy-looking dataset nobody trusts. The honest positioning for an interview is therefore: it is a real, documented approach with a genuinely good idea at its centre - independent attributes drawn from short fixed lists, captured partly at open and partly at close, read as distributions rather than as individual records. It is worth knowing about, worth borrowing the qualifier dimension from even if you adopt nothing else, and worth adopting in full only where the volume of defects is high enough that distributions mean something and the team will actually keep the values consistent.