Main idea

When the obligation to fix immediately applies, the team slows down, sometimes a lot. The immediate conclusion is that the rule is too harsh.

The cause is elsewhere: the production system manufactures too many defects, or detects them too late. The defect queue was acting as a shock absorber — it spread that rate over time and made it illegible. The rule removes the absorber; the rate becomes a daily constraint.

The answer therefore bears on production: tests, QA, TDD, automation, clearer specifications, developer accountability for what they ship. Not on restoring the absorber.

Why it matters

The pain created by the rule is an instrument of measurement, and that is its main value. Reading it as a failure leads to reinstalling the queue, that is, to re-masking what you have just discovered.

Nuances and limits

The rule says nothing about the acceptable fixing delay, nor about what a team can absorb. A team that discovers an unmanageable rate needs a transition, not immediate enforcement.

Open questions

• How long can a team hold a defect rate its system doesn't yet know how to reduce?