What is defect density, and why does the denominator you choose change the answer?

## The ratio Defect density is a normalised defect count: defects attributed to a piece of software, divided by a measure of that software's size, over a stated window. density = confirmed defects / size units Dividing is the whole point. A bare count of 84 defects says nothing — 84 in a three-week-old prototype and 84 in a five-year-old billing subsystem are not the same fact. Normalising lets you put two components, two releases, or two suppliers' deliverables side by side, and it is the only way to turn "is this module worse than that one?" into a question with an answer. ## Three things must travel with the number **The numerator — what counted as a defect.** Every filed report, or only confirmed ones? Are duplicates, cannot-reproduce, works-as-designed and enhancement requests stripped out? Are all severities in, or only those above trivial? Two teams with different filing cultures produce incomparable numerators from identical software. **The denominator — the size unit.** Thousand lines of code, functional size units, endpoints, screens, features, stories, or modules. **The window — where and when.** Defects found in which activity (review, unit testing, system testing, the field) and across which build range. A density from the first week of system testing and a density from twelve months in the field measure different things. Quote a density without all three and it is not readable, only repeatable. ## Why the denominator decides the answer **Lines of code** are cheap to obtain and the most common choice, but they measure the solution rather than the problem. Verbose or generated code inflates the denominator and flatters the ratio; a rewrite that removes duplication without changing behaviour shrinks the denominator and makes the density look worse. The counting rule is itself contested — comments, blank lines, test code, generated files and vendored code are all in or out depending on who counts. **Functional size** units count what the software does rather than how much text expresses it, so they compare across implementations and technology stacks — at the cost of a trained counter and real effort per release. **Feature, story or endpoint** units are cheap and legible to product people, but the units are wildly uneven: one story is an afternoon, another is a fortnight. **Per module or per file** is fine for ranking inside one codebase whose modules are broadly comparable, and close to meaningless across codebases. ## A worked example A subscription renewal job ships with 12,400 executable lines and 27 confirmed defects found in system testing — 2.18 per thousand lines. The team then extracts a duplicated proration routine, dropping the component to 7,900 lines and finding 3 further defects while doing it. The cumulative figure is now 30 defects in 7,900 lines: 3.80 per thousand. The code got better and the number got worse. Nothing about the product moved in the direction the metric moved; the denominator did. The same release's currency-rounding drift shows the numerator problem. It was filed four times by three testers before triage merged the reports. Counted raw, that single fault contributes four to the numerator; counted as confirmed-unique, one. A factor of four on a small numerator swamps any real difference you were hoping to see. ## Skew Defects are not spread evenly. It is a repeated observation in the testing literature — usually called defect clustering — that a small proportion of components carries a disproportionate share of the defects. The precise split varies by system and by study, so quoting a fixed ratio as a law overstates the evidence. The practical use is real, though: rank components by density and let the ranking direct extra review, extra testing, or a rewrite decision. Guard against the feedback loop. Attention finds defects, so whichever module you look at hardest keeps topping the table. Cross-check a density ranking against change frequency, structural complexity, and where field-reported defects actually land. ## What the number cannot tell you Density measures defects **found**, not defects **present**. A low density is equally consistent with clean code and with weak testing, so it is only readable next to a measure of what escaped — defects reported from the field over a fixed window after release. On its own it is not a quality verdict, and the moment it is set as a target the numerator starts to move for reasons that have nothing to do with the software.