Quality-driven development
Quality is what the next change costs.
That is the whole claim. Everything a team calls “quality” — tests, reviews, naming, coupling, documentation, observability — shows up in exactly one number that anyone outside engineering can feel: how long the next change takes and how confident anyone is when it ships.
It makes quality an economic property. That matters because economic arguments survive a budget review and moral ones do not. “We should write tests because it is professional” loses to a deadline. “Untested code costs us four days per release in manual regression, and that number grows with the codebase” is a number someone has to argue with.
Why “quality-driven” and not “quality-assured”
Section titled “Why “quality-driven” and not “quality-assured””Assurance is a check performed on something already built. Driving means the quality attributes are inputs to the design, and the difference is visible in when the conversation happens.
Assured: build it, then find out whether it is fast enough.
Driven: state that a search must return in under 300 ms at the 95th percentile under 200 concurrent users, and let that constrain the design — because a requirement that arrives after the architecture is a rewrite, and a requirement that arrives before it is a decision.
The quality attributes are requirements
Section titled “The quality attributes are requirements”A quality attribute with no owner, no threshold and no test is a wish. This is the single most common failure, and it looks like a non-functional requirements section that says “the system shall be performant, secure and maintainable” — a sentence nobody can fail.
A quality attribute becomes a requirement when it has three things:
A threshold. Not “fast” — 300 ms at p95 under a stated load. Not “secure” — no critical or high CVEs in shipped dependencies, no OWASP Top 10 category unaddressed on authenticated endpoints.
An owner. A named team, not a department. The team that can change the system’s behaviour is the team that owns the attribute.
A check. Something that runs and can fail. This is where the attribute meets the typologies: every threshold above has a level it belongs at, and if you cannot name that level the threshold is not yet a requirement.
What a defect actually tells you
Section titled “What a defect actually tells you”A defect in production is feedback about the process, not about a person. The useful question is never who missed this — it is:
At which level should this have been caught, and why was there no test there?
The answers cluster, and each has a different fix:
| Answer | What it means | What to change |
|---|---|---|
| “There was a test, it was wrong” | The test encoded the same misunderstanding as the code | The specification, upstream — see shift-left |
| “The level was too high” | Caught in E2E, should have been a unit test | Move it down; delete the slow one |
| “The level was too low” | Passed in isolation, broke in composition | An integration or contract test is missing |
| “It only happens with real data” | Test data does not resemble production | Test data strategy |
| “It only happens under load” | It is a performance property, tested functionally | Performance |
| “We decided not to test this” | The risk model worked; the bet lost | Nothing. Record it and move on |
That last row is important and is almost never allowed. A conscious risk that materialises is not a failure of the process — it is the process working, at the cost it advertised. Treating it as a failure is how teams learn to stop making their risk decisions explicit. See risk-based testing.
The measures worth watching
Section titled “The measures worth watching”Two, and neither is a coverage percentage.
Change lead time and change failure rate. How long from commit to production, and what fraction of changes cause a degradation. Quality shows up here before it shows up anywhere else: a codebase people are afraid of has a slow lead time because every change gets a manual regression, and a high failure rate because the manual regression misses things.
Escaped defect level. Not the count — the level at which each escaped defect should have been caught, from the table above. The count tells you how bad last month was; the distribution tells you which part of the strategy is not working.
Coverage is not on the list. It measures what ran, not what was verified, and it is the easiest number in engineering to move without improving anything. See coverage for what to use instead.
Where this connects
Section titled “Where this connects”The development practices this rests on live in the neighbouring hub: test-first as a design technique, contract-first as a coupling decision, and the rituals that put a tester in the room before the code exists. See dev-hub.