Main idea

The pattern is widespread: a developer ships a feature, moves on to the next subject, and the defects that surface are picked up by someone else — a free developer, someone on rotation, a technical support team, sometimes a team dedicated to bugs. The assignment criterion is availability.

Optimizing for availability looks like a scheduling gain. The real effect lies elsewhere. Whoever introduced the defect never sees what their shipment cost. Whoever fixes it has to reconstruct a context they did not create, so they pay twice: for the fix and for the understanding. And the lost time, having become collective, stops being attributable to a specific shipment.

The system then emits a signal nobody states out loud: you can ship fast, and if it breaks, someone else will absorb it. "I'd already moved on to something else" becomes an acceptable answer.

Why it matters

This shifts the diagnosis of a team that produces too many defects: before looking at its skills or its tooling, look at its rule for assigning fixes. A rule that optimizes short-term throughput can be what feeds the flow to be fixed.

It also gives a reading of teams "dedicated to bugs": they are not merely a way of organizing, they are a device that cuts the link between a shipment and its cost.

Nuances and limits

Assignment by availability is not always avoidable — a developer who has left, a defect stemming from several contributions, a legacy area with no identifiable author, someone objectively better placed. These cases exist and are not in dispute.

What is in dispute is their use: they often serve to justify the opposite general rule, where availability decides by default rather than by exception.

Open questions

• How do you attribute a defect stemming from several successive contributions without turning the attribution into an investigation more costly than the fix?