Main idea

Legacy gets told as an inheritance: old code, past decisions, fragile architectures, poorly documented dependencies, choices that made sense yesterday. Presented that way, it is suffered — you inherit it, you live with it.

The share you do not suffer is the one you are writing right now. A defect handed off to someone else, a vague specification accepted without discussion, a test never written, a regression replayed by hand sprint after sprint, a QA used as a final net, code shipped fast and poorly understood: each of these gestures is a dated concession, and each becomes one line of the legacy the team will discover in two years.

What they have in common is not haste. It is a displacement: responsibility for quality leaves whoever could still exercise it, and the product keeps the trace of that displacement long after everyone has forgotten the constraint that motivated it.

Why it matters

This turns an inevitability into something you can arbitrate. As long as legacy is an inheritance, it calls for remediation plans; once seen as current production, it becomes a consequence of decisions taken this week, and ones you can act on without a dedicated budget.

It also gives a list of leading indicators: the deferral gestures listed are immediately observable, whereas their effect is not visible for years.

Nuances and limits

Not every deferral is a fault. Some debts are contracted knowingly, for a dated reason, and get repaid — the difference lies in their being named as such at the moment they are taken on.

And legacy does not come only from concessions: a technology ages, a market changes, a sound architecture becomes unsuited without any gesture of deferral having taken place.

Open questions

• How do you recognize, at the moment you do it, that a deferral is a named debt rather than an ordinary concession?