Technical Debt Explained
What Ward Cunningham's debt metaphor originally meant, the different kinds of technical debt, how to make it visible, and how to pay it down within normal delivery.
The Agile Coach · Last reviewed October 21, 2026 · 5 min read
"Technical debt" is one of the few programming terms that has escaped into everyday business conversation. Executives use it in budget meetings, product managers mention it in roadmaps, and developers invoke it when explaining why a seemingly simple change will take weeks.
Like any popular metaphor, it has been stretched. Sometimes it is used to mean any code a developer dislikes; sometimes it becomes an excuse for cutting corners. Going back to where the idea came from, and looking at how thoughtful practitioners use it today, makes it far more useful.
This guide covers the original metaphor, the different kinds of debt, ways to make debt visible to non-technical stakeholders, and practical approaches to paying it down without stopping delivery.
Where the Metaphor Came From
The term comes from programmer Ward Cunningham. In an experience report presented at the OOPSLA '92 conference, about a financial product called the WyCash Portfolio Management System, he wrote that "shipping first time code is like going into debt" and that a little debt speeds development so long as it is paid back promptly with a rewrite.
Cunningham later explained in a video that he chose the financial analogy to explain the refactoring his team was doing to his boss, since they were building financial software. Refactoring means restructuring code without changing what it does. His point was that as the team learned more about the problem, the code needed to be updated to reflect that understanding. Failing to do so would leave them stumbling over the mismatch, which was like paying interest on a loan.
He also pushed back on a common reading of his metaphor. In that video he said he was never in favor of writing code poorly, but he was in favor of writing code that reflects your current understanding of a problem, even if that understanding is partial. Debt, in his original sense, is the gap between what the code says and what the team now knows.
Principal and Interest
Martin Fowler's explanation extends the analogy. The extra effort it takes to add new features because of messy or outdated internal structure is the interest. Cleaning up that structure is paying down the principal. Paying principal costs time now but reduces the interest on every future change in that area.
This framing helps with decisions. Code that nobody touches accrues little interest, even if it is ugly. Code that changes every week in a tangled area charges interest constantly. That is where paying down debt pays off.
Kinds of Technical Debt
Not all debt arises the same way. In 2009 Fowler proposed a technical debt quadrant that sorts debt along two axes: whether it was taken on deliberately or inadvertently, and whether the decision was prudent or reckless. That produces four broad situations:
- Deliberate and prudent: a team knowingly takes a shortcut to hit an important date and plans to fix it afterward.
- Deliberate and reckless: a team skips design because it feels there is no time, underestimating how quickly the mess will slow it down.
- Inadvertent and reckless: problems caused by a lack of knowledge of good design practices.
- Inadvertent and prudent: a good team finishes something and only then realizes how it should have been designed, which Fowler considers inevitable for teams that are learning.
Beyond the quadrant, people often speak of debt in specific areas: outdated libraries and frameworks, missing automated tests, manual deployment steps, unclear documentation, or architectural decisions that no longer fit how the product is used.
Making Debt Visible
Debt is invisible to most stakeholders, which is why it tends to grow. Teams that manage it well find ways to show it. Useful approaches include:
- Recording significant debt items in the same backlog as features, with a short note on the cost of leaving them.
- Describing debt in terms of its effects, such as slower changes, recurring bugs or risky releases, rather than in code jargon.
- Tracking trends the team already measures, such as how long changes take or how often deployments fail, and connecting them to known problem areas.
- Mentioning debt in sprint reviews when it affected what the team could deliver.
A hypothetical example: rather than saying "the billing module needs refactoring," a team might say "every pricing change takes about a week because of how billing is structured; a two-sprint cleanup would let us make most of those changes in a day or two." That gives a product owner something concrete to weigh.
Paying It Down Within Normal Delivery
Large "rewrite" projects that pause feature work are risky and hard to justify. Many teams instead pay debt down continuously, as part of everyday work.
Fowler suggests that gradual improvement works well because it naturally focuses effort where the code is changing most. A common habit is to tidy the area you are already working in: when a feature touches a messy part of the system, leave it a bit cleaner than you found it. Practices such as automated tests, continuous integration and regular refactoring make this safe.
Some teams also reserve a consistent share of each sprint for improvement work, or include cleanup tasks directly in the stories that need them. The key is that the whole team, including the product owner, understands and agrees to the approach, so improvement work is not hidden or squeezed out.
Using the Metaphor Honestly
The debt metaphor works best as a communication tool for real trade-offs. It is weakest when used to justify sloppy work or to label every disagreement about code style. Fowler notes that the numbers involved are estimates, not precise calculations. Taking on deliberate, prudent debt can be a sound business decision, provided the team is honest about it and plans to repay it.
Key takeaways
- Ward Cunningham introduced the debt metaphor in a 1992 OOPSLA experience report about the WyCash system.
- His original meaning was about updating code as understanding grows, not about writing poor code on purpose.
- Interest is the extra effort caused by messy structure; focus repayment where code changes most.
- Fowler's quadrant separates deliberate from inadvertent and prudent from reckless debt.
- Make debt visible in business terms and pay it down steadily as part of normal work.
Sources
Spotted something out of date? Let us know.