Technical debt

Short definition

A weakness in a piece of software's design or architecture that the company has decided will be handled, and which on that count carries a cost of repayment and a place in the priorities. As long as that decision isn't taken, the weakness remains a discomfort or a latent risk.

Full definition

In ordinary usage, the word covers everything a developer regrets in an existing code base: an old shortcut, a weak architecture, accumulated complexity, an obsolete library. The financial analogy there is purely descriptive — you speak of debt to say something will cost more later, without any creditor, due date or amount being named.

In the articles on this blog, the word is reserved for what has crossed a decision. A weakness known for years, that nobody has put on the programme, isn't a debt: it has no date, no arbitrated cost, no one responsible for repayment. It becomes one when the company judges that the cost of carrying it exceeds the cost of handling it — because it blocks a strategy, slows the team badly, exposes it to a risk, degrades the quality the customer perceives, or prevents an important product change.

Field usage diverges markedly from the sense retained here: in the field, "we have debt" designates a permanent state of the system, and triggers nothing. The sense retained here makes the word a status that is acquired, not an observation that is repeated.

Usage in the field

Prioritization review between a product subject and a technical subject, a developer's argument before a committee, the decision to let a technical subject into the roadmap, defining a handling strategy distinct from day-to-day bug management.

Synonyms and variants

"the debt" for short · "architecture debt" when the weakness is structural · "technical discomfort" and "latent risk" for the state prior to the decision.

Not to be confused with

• Defect — a gap between a piece of software's expected behaviour and its real behaviour; debt has no visible faulty behaviour, it costs in evolution.
• Zero bug policy — the regime that forbids keeping a known defect without a decision; it bears on gaps in behaviour, never on design weaknesses.
• Roadmap — the view of major subjects committed, prepared and possible; technical debt figures there only after the decision to handle it.
• Understanding debt — the gap between what a team has produced and what it knows about what it produced; it is paid in an inability to decide what to rebuild, where technical debt is paid in rebuilding work.
• Refactoring — the gesture of improving code internally without changing behaviour; it is a means of repayment, not the debt itself.
• Essential complexity — difficulty inherent in the problem being handled, which no architectural work removes.
• Reconstructibility — the property of a system a team would know how to rebuild elsewhere from its contracts, its business rules and its tests; it qualifies what you can say about the system, not the quality of its design.
• Understanding debt — the gap between what a system does and what the team answering for it can explain; it bears on the heads of those who maintain it, where technical debt bears on the state of the code, and it waits for no decision in order to exist.

Examples

A weak architecture, known about for a long time, that prevents nobody from shipping: discomfort, not debt.

The same architecture, on the day it blocks a strategic project and the company decides to take it on: debt, with a place to find among the priorities.

Ambiguities / debates

The financial analogy is contested: debt presupposes voluntary borrowing, whereas a large share of what the word covers was accumulated without a choice, through ignorance or deadline pressure. Some propose reserving its use for deliberate shortcuts.

A second wobble, more operational: should technical debt be counted in the team's capacity or among the roadmap's subjects? Both answers circulate, and they don't involve the same arbiter.