A Deep Dive on the Term "Technical Debt"
A Deep Dive on the Term Technical Debt
How the term technical debt traveled from one manager's desk in 1992 to every standup meeting in software.
Ward Cunningham borrowed a word from finance to explain a coding tradeoff to his boss. Thirty-four years and several extensions later, the metaphor has outgrown its original job — and picked up a new one nobody assigned it: describing code that isn't written by people at all.
By Aaron Rose · Tech Reader Magazine · July 15, 2026
Podcast 🎧 • Video 📽
A programmer sits down to write an experience report for a conference. He has just finished explaining, again, why the team needs time to rewrite code before adding the next feature. His manager doesn't think in code. He thinks in numbers, deadlines, and risk. The programmer reaches for the closest thing to a shared language between them — debt, interest, payment — and writes it down. He has no way of knowing the metaphor will outlive the product, the company, and the conference it was written for.
The Origin
In 1992, Ward Cunningham, a programmer working on a financial product called WyCash at Wyatt Software, needed a way to explain something to his manager. The team was using an early iterative approach — write code, learn from it, rewrite — at a time when the dominant model for building software was waterfall: plan everything up front, build it once. Cunningham needed his manager to understand why the team had to pause and rewrite code before adding new features, rather than simply pushing forward.
He reached for a financial metaphor. In an experience report submitted to the OOPSLA conference that year, he wrote that shipping first-time code is like going into debt — a little debt speeds development, so long as it's paid back promptly with a rewrite. The danger occurs when the debt isn't repaid. Every minute spent on not-quite-right code counts as interest.
The metaphor was specific in its original form. It described the gap between a team's current understanding of a problem and the code they'd already written based on an earlier, less complete understanding. As the team learned more, the existing code became not-quite-right relative to that new understanding — not because anyone had done sloppy work, but because iterative development means your model of the problem keeps improving while the code lags behind it. The interest was the extra effort required to build new features on top of that gap. The payment was a rewrite — what would later come to be called refactoring, a term not yet in common use in 1992.
It was, in Cunningham's own framing, a description of a normal and often reasonable tradeoff. Going into debt to move faster wasn't a mistake. Failing to pay it back was the problem.
1992
The year Ward Cunningham introduced the debt metaphor in an OOPSLA experience report on the WyCash Portfolio Management System — three years before "refactoring" entered common engineering vocabulary.
How the Term Changed
Technical debt did not stay inside that original frame. Martin Fowler's 2003 bliki post introduced the metaphor to a much wider audience outside the OOPSLA community, and his 2009 follow-up, the Technical Debt Quadrant, gave the field its most cited framework: a 2x2 matrix crossing deliberate versus inadvertent debt with prudent versus reckless debt. This was an expansion of the original idea — debt could now be something a team chose carelessly, not just something that accumulated as an honest byproduct of learning.
Steve McConnell's 2007 IEEE Software article added further categories: unintentional debt, produced through lack of knowledge or process; short-term debt, taken on deliberately for near-term gain; and long-term debt, which builds up through a system's natural evolution. McConnell also formalized the principal-and-interest framing that's now standard — principal being the cost to fix something, interest being the ongoing tax paid for not fixing it.
Going into debt to move faster wasn't the mistake. Failing to pay it back was the problem.
By the time Philippe Kruchten and others published a seven-category taxonomy in the early 2010s, technical debt had grown to cover code debt, architecture debt, requirements debt, documentation debt, test debt, and more. Each extension made sense on its own terms — these were all real categories of accumulated cost in a software project. But the cumulative effect, as software architect George Fairbanks observed in a 2020 retrospective, was that the term had drifted a long way from Cunningham's original, narrower idea. Fairbanks proposed calling that original formulation ur-technical debt specifically to distinguish it from the broader, looser usage that had taken over the term by then.
How the Term Is Used Now
Today, the term technical debt functions as a catch-all in software organizations. It shows up in sprint planning, in code review comments, in roadmap conversations between engineering and business stakeholders. It's used to describe legacy systems that are hard to modify, code that one engineer finds confusing, gaps in test coverage, outdated dependencies, architectural decisions made years earlier under different constraints, and simply any code a current developer would have written differently.
This breadth is itself notable. Cunningham's metaphor was built around a fairly specific mechanism — the cost of acting on yesterday's understanding of a problem. The term now does double duty as a general-purpose label for "things in the codebase we'd like to fix but haven't."
When the Term Becomes Vague
Some practitioners, writing as recently as 2025, have argued that the term has become so elastic it risks losing analytical usefulness — that technical debt can function as a label that names a discomfort without specifying its cause, which makes it harder to decide what to actually do about it. Others maintain the opposite view: that the elasticity is a feature, because it gives engineers a shared vocabulary that translates technical cost into terms a non-technical stakeholder can reason about — which was the entire point of Cunningham's original move.
AI Coding and Technical Debt
The metaphor has also picked up new material to describe. With the rise of AI coding assistants, early research from organizations including Faros AI and CodeScene has begun examining whether AI-generated code shows different debt-accumulation patterns than hand-written code — higher churn, for instance, relative to its complexity. The underlying Cunningham observation — that shortcuts accrue interest regardless of who or what wrote them — appears, by early indications, to apply whether the "first-time code" was written by a person learning a problem or a model generating a plausible-looking solution quickly.
This is a new domain for an old metaphor, three decades after its coining, applied to an authorship question that didn't exist when the term was invented. Cunningham was writing about the gap between a programmer's evolving understanding and code already shipped. An AI model has no evolving understanding in the same sense — it generates output based on a fixed model, not a learning process unfolding inside the same team over time. Whether the debt metaphor maps cleanly onto that difference, or simply gets stretched to fit it, is an open question the field is only beginning to ask.
The financial metaphor's vocabulary still does the same basic job it did in 1992: it gives engineers and non-engineers a shared frame for talking about deferred cost.
A Metaphor for Engineering Tradeoffs
What's consistent across this thirty-plus-year arc is not the content of the term but its function: technical debt is borrowed language, brought over from finance to make an engineering tradeoff legible to people who don't think in code. That transplant succeeded well enough that the term outlived its original, narrow context and kept being reapplied to new situations — broader categories of cost, new development methodologies, and now a new category of code author.
Each reapplication changes, slightly, what the term is doing. The vocabulary — principal, interest, payment, default — still does the same basic job it did for Cunningham in 1992: it gives engineers and non-engineers a shared frame for talking about deferred cost, even as what falls under that frame keeps expanding.
Next in the Series
Technical debt isn't the only engineering term doing rhetorical work its coiners never assigned it. A continuing look at the vocabulary the industry inherited — and what gets lost in translation. At Tech Reader Magazine.
Tech Reader Magazine
TechReaderMagazine.com