Delivery versus Maintainability

Definition

Technical debt is the future cost of a present shortcut. Like financial debt, it is a legitimate instrument: borrowing to reach a market window can be entirely correct. The failures are borrowing unknowingly, and never repaying.

The four kinds, which need different responses

• Deliberate and prudent — "we ship the simple version to validate demand, and we know what it costs." Correct, and it should be recorded with the repayment condition.
• Deliberate and reckless — "we do not have time for design." Occasionally justified in a genuine emergency; usually a habit.
• Inadvertent and prudent — "now that it is built, we see the better design." Unavoidable and healthy; this is learning.
• Inadvertent and reckless — the team did not know better. Addressed by capability, not by process.

Naming which kind you are taking on changes the conversation from a moral one to an engineering one.

Making the trade visible

• Record it at the moment it is taken, with what was skipped, what it will cost, and what would trigger repayment. An undocumented shortcut is indistinguishable from a mistake within six months.
• Attach it to something observable — a slowing feature, a recurring incident, a rising change failure rate. Debt argued in the abstract loses to features every time; debt argued as "this is why the last three changes took three times as long" wins.
• Express repayment as capability, not tidiness. "This refactor lets us add a payment method in a day instead of three weeks."

When to refuse the trade

• In the foundations. Data models, security boundaries, tenancy and identity are extremely expensive to change later, and shortcuts there compound.
• When the shortcut is invisible in testing, such as a missing idempotency guarantee. Debt whose interest is paid in incidents is worse than debt whose interest is paid in effort.
• When the team is already at capacity servicing existing debt. Past a point, all capacity goes to interest and none to principal, and the only exit is a deliberate investment period.

The signals that the balance is wrong

Feature estimates growing for similar work; the same area causing repeated incidents; onboarding taking much longer than it used to; engineers routing around a component rather than changing it.

Failure scenarios

• Debt taken without recording it, becoming invisible and unattributable.
• Refactoring justified aesthetically, which product will correctly decline.
• A rewrite proposed where incremental improvement would do, because the debt was allowed to accumulate past the point of tractability.
• Repayment always deferred, so the interest consumes the team.

Interview question

"How would you make the case for a two-sprint refactor to a product manager under delivery pressure?"