Main idea

A zero bug policy deals with the stockpile. It forces the decision, it prevents known defects from being hidden in a queue. It changes nothing about the way the team designs, specifies and ships.

A team that fixes fast without changing how it produces stays in a repair loop: same defect rate at the input, same load, only the queue has gone. Preventing the stockpile from re-forming is another kind of work — developers owning what they ship, clear specifications, TDD, QA, automation, anticipating the legacy being written right now.

Layer added by "Quality belongs to those who ship" (2026-06-03). The second problem has a name and a content of its own: delivery quality. It doesn't break down into a project but into a shift of position — the fix handed back to whoever shipped, the right to refuse a specification you don't understand, the expected behavior formalized before implementation, a QA that writes the framework instead of holding the last line. What these levers have in common is that none of them acts on existing defects: they all act on the place in the chain where quality is decided.

What makes the confusion durable is that both problems are measured in the same place. A team that has emptied its stockpile and fixes fast shows the same indicators as a team that produces few defects — until the repair loop becomes visible: the backlog shrinks then climbs again, the fires go out then flare back up, support catches its breath then gets swamped again.

Why it matters

This keeps you from expecting of a rule what it never promised, and then concluding it failed because defects keep arriving. The rule never bore on how things are built.

It also says where the next investment goes, once the stockpile is dealt with.

Nuances and limits

The two are not strictly sequential. Making the cost of defects visible and daily is often what finally triggers investment in prevention.

Open questions

• What share of the defect rate comes from the delivery system, and what share from product design?