Technical debt, defined
Updated
Technical debt is the future cost created when a system diverges from what the team now knows it should be — extra effort that every subsequent change must pay, like interest on a loan. Paying the principal means reworking the code; not paying means compounding interest on every change.
Ward Cunningham coined the metaphor in a 1992 OOPSLA experience report. It has since stretched to cover everything from a deliberate shortcut under deadline to decade-old unmaintained dependencies — which is why any serious use of the term starts by saying which kind of debt is meant.
The metaphor, and what it actually says
Cunningham's original point is narrower and sharper than the common usage. Shipping code embodies your current understanding of the problem; as understanding improves, the gap between what the code is and what you now know it should be is the debt. Taking on debt can be rational — shipping sooner buys learning — but the debt must be repaid by refactoring the code toward the improved understanding, or every future change pays interest in the form of extra effort, defects, and slowed delivery.
The metaphor earns its place in executive vocabulary because it prices a trade-off. It was never a euphemism for sloppy work: in Cunningham's framing, writing poor code is not borrowing, it is simply losing money. The useful question the metaphor poses is not whether debt exists — it always does — but whether it was taken on knowingly, whether the interest is being tracked, and whether anyone is scheduled to repay the principal.
Deliberate vs inadvertent debt
Martin Fowler's technical-debt quadrant splits debt along two axes: whether it was taken on deliberately, and whether the decision was prudent or reckless. The distinction matters operationally, because each kind is found and repaid differently — deliberate debt can be logged at the moment it is incurred, while inadvertent debt only surfaces later, through measurement or through the pain of changing the affected code.
| Deliberate | Inadvertent | |
|---|---|---|
| Prudent | A conscious shortcut with the cost understood — ship now, log the debt, schedule the repayment. | The design was reasonable at the time; only with hindsight does the team see the better approach. |
| Reckless | Skipping design and quality knowingly, with no plan or intention to repay. | The team lacked the skill or context to see the debt being created at all. |
Measuring it honestly: the denominator matters
Most technical-debt numbers fail on the denominator. A count of static-analysis findings is meaningless without knowing how much of the estate was analyzed; an estimate of remediation hours is meaningless without knowing what fraction of the codebase it covers. A debt score computed over the three repositories that were easy to scan, presented as if it described the whole engineering organization, is not a measurement — it is an anecdote with a decimal point.
An honest technical-debt measure states its coverage explicitly: which systems were measured, by what method, and — critically — which were not. It normalizes findings against the size of what was actually examined, so the number cannot be improved by scanning less. And it separates the signal (dependency age, unsupported runtimes, duplication, missing tests in changed code) from the interpretation (how much that costs this business), because the second is a judgment the first should inform, not replace.
- State the denominator: findings per unit of measured code, never raw counts.
- State the coverage: what share of the estate was actually examined, and what was not.
- Report the unmeasured as unmeasured — an unscanned system is unknown, not debt-free.
- Track the trend under a fixed method; a number that improves because the method changed is noise.
Why technical debt belongs in board reporting
Boards review financial leverage every quarter because debt constrains what the company can do next. Technical debt constrains the same things — delivery capacity, security exposure, the cost of the next strategic pivot — and it surfaces at the worst moments: due diligence, an incident post-mortem, or the quarter a critical dependency reaches end of life. A board that sees delivery slowing without a debt measure is left guessing whether the cause is headcount, market, or the codebase itself.
The reporting bar is the same honesty bar as above. A board-facing debt number is only worth presenting if it states its coverage, is computed from observed evidence rather than impression, and reports anything unobservable as unmeasured instead of estimating it. A number that quietly extrapolates over unmeasured systems fails precisely when it matters — when someone asks what it is based on.
Frequently asked questions
Who coined the term technical debt?
Ward Cunningham, in a 1992 experience report at the OOPSLA conference, describing work on a financial software system. He used the debt metaphor to explain why shipping code ahead of full understanding can be rational — provided the code is later reworked to match what was learned.
Is technical debt always bad?
No. Prudent, deliberate debt — a conscious shortcut with the cost understood and repayment planned — is often the right business call, because shipping sooner buys learning and revenue. Debt becomes destructive when it is taken on unknowingly, left untracked, or never repaid, so the interest compounds silently.
How do you quantify technical debt?
By combining observable signals — dependency age and support status, unsupported runtimes, code duplication, test coverage of changed code, static-analysis findings — normalized against the size of what was actually measured. No single number captures it; the discipline is stating coverage and method, and reporting unmeasured systems as unknown rather than clean.
Is technical debt the same as bad code?
No. Bad code is one source of debt, but well-written code becomes debt when the requirements, scale, or the team's understanding move past the design it embodies. Conversely, ugly code in a system nobody needs to change carries little interest — debt is priced by the changes it taxes.
Should technical debt be reported to the board?
Yes, on the same logic as financial leverage: it constrains delivery capacity, security posture, and strategic options, and it surfaces during due diligence whether or not management measured it first. The requirement is an honest measure — explicit coverage, fixed method, unmeasured reported as unmeasured.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.