What Is Technical Debt? A Clean Definition for Engineering Leaders
Updated 17 April 2026
Technical debt is the extra future work a team takes on when it chooses a short-term solution that it would not choose under normal quality standards, knowingly or not.
Ward Cunningham's Original Metaphor (1992)
The term was coined by Ward Cunningham in his 1992 OOPSLA experience report on the WyCash portfolio management system, a Smalltalk application he was building with his team. Cunningham needed a way to explain to non-technical stakeholders why the team needed time to rewrite early code before adding new features.
Cunningham, 1992:
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."
Cunningham chose "debt" deliberately. "Kludge" and "cruft" were already terms of art, but they carried only negative connotations. Debt, by contrast, is a legitimate financial instrument. It has a principal, an interest rate, and a payoff schedule. The metaphor reframed the conversation from "this code is bad" to "this code is an obligation we are choosing to carry."
Martin Fowler picked up the metaphor in a 2003 bliki post that brought it to a wider audience, and formalised it further with his 2009 Technical Debt Quadrant. See the full history page for the complete timeline from 1992 to 2026.
Five-Way Comparison: Debt, Bug, Rework, Code Smell, Refactoring
These five terms are used interchangeably in many codebases, but they are distinct. Conflating them leads to wrong budgeting decisions.
| Concept | Definition | Trigger | Who pays | Was it a choice? |
|---|---|---|---|---|
| Technical Debt | Design-level shortcut that inflates future change cost | Deliberate trade-off or inadvertent decision | Future engineers doing future work | Sometimes deliberately |
| Bug | Deviation from specification causing incorrect behaviour | Defect in implementation | Current sprint or production on-call | No -- it is a mistake |
| Rework | Doing work again because the first attempt failed | Requirement change, miscommunication, escaped defect | The team that built it originally | No -- it is waste |
| Code Smell | Surface-level indicator of possible structural problem | Observed during review or analysis | Anyone who reads the code | Rarely deliberate |
| Refactoring | Improving code structure without changing behaviour | Planned or opportunistic improvement | Engineers doing the refactor | Yes -- it is the repayment |
Three Worked Examples
Example 1 -- Intentional Debt
Hard-coded credentials on a Friday launch
The team is shipping v1 authentication at 5pm on the day before launch. The OAuth integration is not ready. The lead engineer hard-codes three API secrets in a config file and marks the tickets for cleanup in the next sprint. The feature works. The debt is real, documented, and has a clear repayment plan.
This is Deliberate + Prudent in Fowler's quadrant. The team knew what they were doing and made a conscious trade-off with a plan to fix it. The debt became reckless if the cleanup tickets were never prioritised.
Example 2 -- Inadvertent Debt
A junior engineer commits a god-class
A junior engineer joins a startup and builds the user-management module as a single 3,000-line class that handles authentication, authorisation, billing, email, and profile. Nobody on the team knew the pattern well enough to object. The code works. Six months later, adding a new permission model requires touching everything.
This is Inadvertent + Reckless. The team did not know better. The fix requires investment in code review culture and architectural mentoring -- see the quadrant page for the remediation pattern.
Example 3 -- Inherited Debt
An acquisition brings a Rails 4 monolith into a Node.js shop
A company acquires a competitor whose core product is a Rails 4 monolith. The acquirer runs Node.js microservices. The M&A team did not flag the architectural mismatch. Now engineering owns a codebase nobody can onboard quickly, with a stack nobody is hiring for, and dependencies that are 18 months out of date.
This is M&A integration debt, one of the six named sources on the /by-source page. The remediation is either a strangler fig migration or a deliberate sunset plan.
The "Is It Debt or Just Bad Code?" Test
Before labelling something technical debt, ask three questions:
- Does it have an interest rate? Is the code area getting touched frequently? Debt in code that is never modified has zero effective interest. Dead code is clutter, not debt.
- Is there a better-understood approach you are deferring? If nobody on the team knows what "right" looks like, it may be a skill gap rather than a trade-off. The remediation is different: training, not refactoring.
- Could it be repaid? If the code cannot be improved without a full rewrite, it may be legacy technical debt rather than current debt. The budgeting treatment is different: operating expense vs capital project.
Why the Definition Matters for Measurement
The SQALE method (SonarSource) measures debt as the estimated remediation cost of all code violations. McCabe complexity measures structural difficulty. Churn-times-complexity (CodeScene) measures behavioural hotspots. None of these is "technical debt" in Cunningham's sense -- they are proxies. Understanding what you are actually measuring matters for making the right intervention.
See How to Measure Technical Debt for a comparison of five measurement methods and when to use each.
Frequently Asked Questions
Is technical debt the same as bad code?▼
No. Bad code is poor quality for its own sake. Technical debt is a deliberate or inadvertent trade-off: a solution that was acceptable at the time but creates extra future cost. The three-question test above helps distinguish true debt from just-bad-code.
Can technical debt be good?▼
Yes. Fowler's Deliberate + Prudent quadrant is the textbook example: choosing a known shortcut to ship on a deadline, with full intention of cleaning it up. The debt is the financing instrument that gets you to market. The reckless quadrants are always harmful.
What is the difference between technical debt and a bug?▼
A bug is an unintended deviation from a specification causing incorrect behaviour. Technical debt is a design-level shortcut that does not necessarily cause incorrect behaviour today but makes future changes more expensive. A bug is a defect; tech debt is an obligation. The distinction matters for budgeting: bugs belong in incident budgets, tech debt in engineering-health budgets.
Continue reading:
Sources
- Cunningham, W. The WyCash Portfolio Management System. OOPSLA Experience Report, 1992.
- Fowler, M. TechnicalDebt bliki. martinfowler.com, 2003.
- Fowler, M. TechnicalDebtQuadrant bliki. martinfowler.com, 2009.
- IEEE Std 1219-1998. Software Maintenance. IEEE, 1998.