Main idea

A developer who takes back a defect they introduced themselves does more than repair. They are the only person in a position to compare what they thought they were shipping with what actually happened. They see where their understanding of the need was incomplete, whether the test that would have caught the case did not exist, whether the specification left the ambiguity they settled on their own, whether the architecture made the error likely.

Another developer fixing it in their place finds the technical cause, not the cause of the decision. They repair the symptom without the information making its way back to the place where it would have changed something.

It is this loop — ship, meet the consequence, recognize what was missing — that produces improvement. It is not a side effect of the fix: it is its main value.

Why it matters

This gives quality policies a design criterion: a policy that optimizes fix time without asking who fixes buys speed by removing the learning.

It also explains the repetition of the same design errors within a team. They do not come from a lack of skill but from an information circuit that never returns to the author.

Nuances and limits

The loop only closes if the defect is attached to its cause, and not merely to its line of code: fixing without naming what was missing upstream produces one more repair.

And it has a delay: the later the defect appears, the less the author remembers what they thought they were doing at the moment of shipping.

Open questions

• Where do you record what the fix reveals — missing test, ambiguous specification, fragile architecture — so that it acts on the next shipment rather than staying in the head of whoever fixed it?