Main idea

The roadmap carries the planned features. Deadlines are visible there, trade-offs are made there, commitments are taken there. Defects stay alongside, as an implicit load to be handled "when we have time".

Yet they consume the same capacity: developer time at the moment of the fix, support time at every workaround explained, product attention at every ticket reread. And they consume what can't be planned — the trust of a customer who meets the same behavior twice, the internal credibility of a team whose irritants are known never to move.

Not writing them down doesn't make them free. It makes them invisible at the only place where trade-offs are made.

Layer added by "Quality belongs to those who ship" (2026-06-03). The same observation turns against the scheduling objection raised against any quality rule: bringing a developer back onto his own defect disrupts the sprint, pushes back the next feature, costs visibly. Quality consumes capacity, and excluding it from the plan doesn't make it free — it only removes the expense from the one place where it is compared with the others.

Why it matters

This undoes the opposition between roadmap and quality, which makes features look like the real work and defects like noise to manage around it. Both draw on the same budget; only one is counted.

The question isn't to find time for defects, then, but to bring them into the plan where time is distributed.

Nuances and limits

Writing them down isn't enough. A defect queue is a form of writing down, and it can sit indefinitely without any real trade-off.

And the load isn't uniform: a defect never encountered consumes nothing as long as nobody runs into it.

Open questions

• How do you put a figure on the support load of a defect before having fixed it?