[Code Smell #6] Technical Debt: Cunningham’s Original Meaning

Key answer: Technical debt is a term coined by Ward Cunningham in 1992. Originally, it meant the gap between code and current understanding—not messy code.

Cunningham stressed that a debt strategy works only when the code is clean.

There is a term developers reach for when explaining refactoring to non-developers: technical debt.

This continues from the previous article, Code Smell #5.

We incurred debt to ship quickly, interest is accumulating, and we need time to pay it back.

Yet the person who coined the term repeatedly said his metaphor was being misused—especially when messy code was called debt.

Ward Cunningham, 1992

Ward Cunningham first used the phrase technical debt in 1992, in an experience report for OOPSLA (Object-Oriented Programming, Systems, Languages & Applications, the object-oriented programming conference) (Paper).

This is the same Cunningham better known as the inventor of the wiki and an early figure in extreme programming.

At the time, he was building financial software. The hard part was the domain.

You cannot fully understand the structure of financial products before starting. So he chose to ship what he understood at the time and continuously incorporate what he learned from using it into the code.

This is where his debt arises: the gap between the understanding captured by the current code and the understanding the team actually has now.

A structure that was correct when first written may no longer fit once you understand the domain better. That is debt; updating the code to match the new understanding is repayment.

In 2009, he left a short video explaining the metaphor again and correcting the misunderstanding. The point was this (Debt Metaphor).

Taking on debt is a strategy for learning quickly, not permission to write terrible code. In fact, a debt strategy works only when the code is clean.

If the code is messy, incorporating what you learn becomes impossible.

This is the key point: in the original concept, debt can arise even in well-written code.

It occurs automatically as your understanding of the world changes over time.

By contrast, much of what we call technical debt today is simply code written carelessly. In Cunningham’s terms, that is not debt so much as a mess.

Fowler’s Quadrant

Still, drawing a line at “only real debt is debt” makes the concept hard to use in practice. Martin Fowler’s 2009 quadrant bridges that gap well (Technical Debt Quadrant).

It uses two axes: intentional versus inadvertent, and reckless versus prudent.

	Reckless	Prudent
Intentional	“No time to design”	“Ship now and accept the cost”
Inadvertent	“What is separation of layers?”	“Now I understand how it should have been done”

The four cells each have a different character.

Intentional · prudent is a business decision. There is a deadline, delay would mean missing an opportunity, and the choice is made with awareness that the cost will come later.

This is the cell where the debt metaphor fits most precisely.

There is one condition: knowing the cost.

Inadvertent · prudent is Cunningham’s original debt. You built the best system you could, then six months later understood the domain better and saw a better structure.

It arises even when nobody did anything wrong. Since this cell cannot be avoided, the only remedy is to establish a repayment cadence.

Intentional · reckless means knowingly cutting corners. It is often called debt, but without a repayment plan it is closer to a loss than debt.

Inadvertent · reckless means it happened because you did not know better. The remedy here is learning, not a refactoring schedule.

The response to the same messy code differs by cell. Teams often talk past each other about debt because they are imagining different cells.

What Do You Pay Interest With?

Financial debt charges money; technical debt charges future change cost. If adding the same feature takes one day without debt and three days with it, the two extra days are interest.

This definition leads to one conclusion: debt in code nobody touches has zero interest.

A module nobody has changed for five years may be extremely messy, but if nobody will change it going forward, there is no reason to repay it. Conversely, small debt in a screen touched every week keeps generating interest.

Many teams rank their debt lists by “how bad is it?” The real criterion should be “how often do we touch it?”

The Git change-frequency query from the previous article is useful here too. The overlap between frequently changing files and low-quality files is where the interest rate is highest.

Adam Tornhill calls finding this intersection and prioritizing it behavior-based code analysis.

The Limits of the Metaphor

The term technical debt is convenient, which is exactly the problem. Almost anything can be put into it.

Bugs, old libraries, designs you dislike, and code you did not write all get called debt. The word then becomes a synonym for “things I want to fix” and loses its original explanatory power.

It is practical to call something debt only when it passes two questions.

1. What did you take it on to gain? You should be able to say whether it bought time or produced learning. If you gained nothing, it is not debt but a mistake.
2. How will you repay it? A debt with no repayment plan does not sustain the metaphor.

Some people reject the metaphor itself. The word debt suggests that you can pay it back someday, obscuring situations where it compounds until repayment becomes impossible.

Some propose calling it contamination or a hygiene problem instead, because it is closer to something that must be continually cleaned up than something repaid.

Still, there is a reason the word debt has survived so long: it is one of the few metaphors that works in conversations outside development.

Cunningham first used the metaphor while explaining the need for rework to his manager. It is not a precise term, but it remains valuable as a translation tool.

How to Manage It in Practice

Keep a list, but do not bury it in the issue tracker. A backlog containing only debt tickets is usually ignored.

Instead, leave notes near the code. Briefly record why the file is this way and what it needs; the next person to open it will see them.

Repay it while you are there. When you are already changing the file, interest is being incurred and the context is fresh in your mind.

That is why the Boy Scout Rule—“leave it cleaner than you found it”—works as a practical debt-management method.

Deciding not to repay is also management. Half the items on a debt list are for recording, not repayment.

Explicitly deciding not to repay an item prevents the same discussion from recurring later.

When taking on debt intentionally, record the condition too. For example, “within two weeks after launch” or “before reaching 10,000 users.”

A debt incurred without a time frame has no repayment date.

Summary

• Technical debt is a term coined by Ward Cunningham in 1992. Originally, it meant the gap between code and current understanding—not messy code.
• Cunningham stressed that a debt strategy works only when the code is clean.
• Fowler’s quadrant divides debt along intentionality and prudence. Each cell calls for a different response.
• Interest is future change cost. Debt in untouched code has zero interest, so there is no reason to repay it.
• If you cannot explain what you gained and how you will repay it, it is not debt but simply a problem.

The next article covers what to do when debt has accumulated beyond what you can manage: repair and reuse, or rewrite from scratch.

It is also where some of the software industry’s most expensive wrong answers have emerged.

Sources and Verification Criteria

• The WyCash Portfolio Management System — Ward Cunningham · Original paper · Verified 2026-08-17 · Basis: original explanation of the 1992 technical debt metaphor
• Debt Metaphor — Ward Cunningham · Author’s original text · Verified 2026-08-17 · Basis: Ward Cunningham’s 2009 explanation of the technical debt metaphor
• Technical Debt Quadrant — Martin Fowler · Author’s original text · Verified 2026-08-17 · Basis: the technical debt quadrant categorized by prudence, recklessness, and intentionality

Continue reading

Code Smell Series

• Previous article: [Code Smell #5] Shotgun Surgery vs. Divergent Change
• Previous article: [Code Smell #4] God Object: A Complete Guide
• Previous article: [Code Smell #3] Ravioli Code: Code Whose Flow Nobody Understands