Where Defects Are Introduced and Where They Are Caught
The stages of a change drawn against where defects actually originate and where they are found — showing why the gap between the two is what determines the cost of building software.
SVG. No sign-up, no email.
Two facts about software defects are well established and rarely drawn together: most defects originate early, in requirements and design, and most are found late, in testing and production. The distance between where a defect enters and where it is found is what determines what it costs.
The shape of the problem#
Read the first lane left to right. The two shaded boxes at the start are where most defects enter: a requirement that was ambiguous and got interpreted, or a design that did not account for a case nobody raised. The shaded boxes near the end are where they are found.
A requirement misunderstood on Monday and found in production six weeks later has passed through design, implementation, review, testing and release, acquiring code, tests and documentation that all encode the misunderstanding. Fixing it means unpicking all of that. The same misunderstanding caught by one question on Monday costs a conversation.
This is why the cost of a defect rises with how long it survives, and the rise is not gentle. It is not that later fixes are harder in themselves — it is that later fixes have more attached to them.
What the third lane is for#
The four items are drawn as a set because they are independent, cheap, and each one moves detection earlier.
Ask a question at requirement time. The most valuable question is usually "what should happen when…" — the case the requirement does not mention. Ambiguity is not resolved by building something and finding out; it is resolved by whoever asked for it, in a minute.
Sketch the design before writing it. Not a document — a diagram on a wall, or five sentences in the ticket. The value is not the artefact, it is that a second person can disagree with the approach before it exists in code.
Review the approach, not only the diff. A code review that starts when the code is finished can find bugs and cannot find the wrong solution. By then, saying "this shouldn't have been built this way" costs a week and is usually not said.
Test the boundaries. Happy-path tests pass on code that fails on empty input, a single item, or two things happening at once — which is where defects actually live.
The one that is hardest to arrange#
Reviewing the approach before implementation is the item with the highest return and the most friction, because it requires interrupting someone before they have anything to show. The usual objection — that it slows things down — is measurable, and it is true for the individual change and false for the quarter.
A useful compromise: for any change expected to take more than about two days, the author writes five sentences on the approach and someone reads them. Small changes skip it entirely. Most of the value is in the large changes, and most of the friction is in applying the ritual to small ones.
Using this diagram#
Take the last five defects that reached production. For each, mark on the top lane where it was introduced and where it was found, and draw the distance between.
Nearly always, the distances are long and the origins cluster in the first two boxes. That result argues for something specific: not more testing at the right-hand end, but a question asked at the left. Teams consistently respond to escaped defects by adding tests, which shortens the gap slightly and leaves the origin untouched.