The phrase now means roughly: our code is bad, and we would like some time to fix it.
It is used to open budget conversations, to explain missed dates, and occasionally to describe genuine negligence. It has become an all-purpose noun for engineering unhappiness, which is convenient, and which has emptied it of the thing that made it useful.
Because the man who coined it was describing something else entirely.
What Cunningham was actually writing about
In March 1992, Ward Cunningham submitted a short experience report to OOPSLA about a product called WyCASH+, a portfolio management system for cash securities built at Wyatt Software. It ran to about four megabytes of Smalltalk. The team was small enough that every engineer kept at least general familiarity with all of it.
The report is mostly about why they built it by incremental growth from a working prototype, and why mature sections had been rewritten many times. Then it names the pitfall.
Not bad code. Cunningham is explicit that the code in question may work perfectly well and be entirely acceptable to the customer. The problem is quantity: too much code that was written before the team understood the problem, and never revisited once they did.
His phrase for shipping it was that it is like going into debt. A little speeds you up, provided it is repaid promptly with a rewrite. The danger is not the borrowing. It is not repaying.
And the interest, in his formulation, is not paid in bugs. It is every minute spent working with code that does not match your current understanding of the problem.
Which makes it a financing decision, not a quality one
Read it that way and the metaphor recovers its teeth.
Debt in Cunningham’s sense is deliberate and often correct. You ship before you fully understand the domain, because shipping is how you come to understand it. Then you go back and reconcile the code with what you learned. He is explicit that this is the alternative to the waterfall approach, which in his analogy amounts to insisting on payment up front and in full.
Nobody argues that taking a mortgage is a quality failure. The question is whether you can service it.
This is why the modern usage is so much less useful. "We have technical debt" describes a condition and asks for sympathy. "We borrowed against an incomplete understanding of the problem in Q1, we now understand it, and we have not repaid" describes a decision, names a moment, and implies an action.
The consequence he named is not the one people worry about
Here is the line that gets skipped, and it is the most valuable sentence in the report.
Cunningham’s warning about excess immature code is that it makes a program unmasterable — which leads, in his sequence, to extreme specialization of programmers, and only then to an inflexible product.
The first casualty is not correctness. It is comprehension. When there is more not-quite-right code than the team can hold, people stop trying to understand the whole and retreat into the parts they own. The system becomes rigid afterwards, as a consequence of nobody being able to see across it.
That is an organizational failure with a code-shaped cause, and it is measurable in ways that "code quality" is not. How many people can safely change this component? Has that number gone up or down in a year? When the person who owns it is away, what stops?
It also connects to something with harder evidence behind it. When Microsoft Research studied Windows Vista in 2008, the organizational measures — how many engineers touched a component, how many had left, how concentrated ownership was — predicted post-release failures better than any code metric they tested. Cunningham described that mechanism sixteen years earlier, from a four-megabyte Smalltalk codebase, without any data at all.
Why the term drifted
The drift is not mysterious. "Debt" carried a connotation of irresponsibility that Cunningham did not intend but could not prevent, and the metaphor was too useful to stay precise. By 2009 he had recorded a video specifically to correct common misinterpretations of his own term — which is a fairly clear signal of how far it had traveled in seventeen years.
What was lost in the drift is the repayment schedule. Cunningham’s version has a rhythm: borrow, learn, consolidate, repeat. His team rewrote mature sections many times, and he treats that as the ordinary cost of the approach rather than as remediation.
The modern version has borrowing and complaining, with no consolidation step. Which is not a debt strategy. It is default with extra reporting.
Two questions that restore the metaphor
If your organization uses the phrase and cannot answer when the debt was taken on or what was learned since, it is not using the metaphor. It is using the word.
Two questions restore most of the value. First: which parts of this system were built before we understood the problem, and do we understand it now? That identifies the actual debt, as opposed to code someone dislikes. Second: how many people can safely change each component, and is that number falling? That measures the interest, in the currency Cunningham said it was paid in.
Neither question is about code quality. Both are answerable this month, and both point at the thing that actually degrades — which is your organization’s ability to understand its own system, not the system itself.
Sources: Ward Cunningham, "The WyCash Portfolio Management System", OOPSLA ’92 Experience Report, 26 March 1992, published at c2.com/doc/oopsla92.html, including the 2009 addendum in which the author corrects common misinterpretations. Nachiappan Nagappan, Brendan Murphy and Victor R. Basili, "The Influence of Organizational Structure on Software Quality: An Empirical Case Study", ICSE 2008.
Related Reading
Independent. No sponsorships. Unsubscribe anytime.