Main idea

"Whoever creates the bug fixes it" reads spontaneously as a handling rule: it would say who does the repair work. Yet its main effect sits upstream of the repair.

A developer who knows their defects will come straight back to them ships differently. They test more, they review more carefully, they are less willing to push a fragile change to hit a date, they are less ready to build on top of a strong ambiguity. The rule is an incentive before it is an assignment.

It guarantees nothing: a conscientious developer can produce a defect, and an assignment rule is no substitute for a production system. What it changes is the private trade-off each person makes at the moment of shipping, when nobody is watching.

Why it matters

This answers the cost objection: applying the rule disrupts the schedule, slows the next feature, brings someone back to a subject they had left. That cost is real, but it is to be compared against the flow of defects it reduces, not only against the repair time it moves around.

It also explains why exceptions are expensive: each exception does not merely move one fix, it weakens the incentive for every shipment to come.

Nuances and limits

The incentive presupposes that the developer had a hold on what they were shipping. Constrained by an imposed deadline or by a specification they were forbidden to question, they suffer the rule without being able to respond to it — and it becomes a sanction.

Nor does it say anything about defects coming from legacy or from several contributions, where the author is not identifiable.

Open questions

• Beyond what delay between shipping and the defect's appearance does the incentive stop acting on the way people ship?