Skip to content

Technical Debt

"Technical debt" is one of the most overused and misunderstood terms in software.

It is invoked to justify rewrites, to defer cleanup, to win budget, to scold past teams, and to describe almost any code someone happens to dislike. By the time the phrase is in the room, the conversation it is meant to enable has usually already gone off the rails.

The original metaphor, coined by Ward Cunningham, was a careful analogy for explaining a specific kind of deliberate engineering trade-off to non-technical stakeholders.1 What it has become in practice is something much more sloppy.

The Debt Metaphor Breaks Down

The financial analogy fails in three important ways:45

  • Code does not accrue interest on its own. Financial debt compounds whether you look at it or not. Code only becomes a problem when you try to change or extend it. Untouched code in a stable system can sit for years without costing anything.
  • Normal aging is not negligence. A codebase built on an older framework is not necessarily sloppy. It is usually a successful product built in the context of the past. Frameworks, idioms, and best practices move. The code did not get worse; the world moved around it.
  • The word "debt" implies a mistake. Calling old features or legacy systems "debt" frames them as failures. In reality, they are often the foundational, successful artifacts that kept the company alive long enough for anyone to be debating them.4789

The metaphor breaks down because it suggests a single quantity that can be measured, balanced, and "paid off." The reality is a portfolio of different problems with very different shapes and very different costs.

Categories of What People Call "Tech Debt"

Rather than treating it as a monolithic pile of bad code, it is more useful to break what people call "tech debt" into specific operational categories:65102

  • Deliberate strategy. A conscious, well-documented trade-off made to ship a feature faster, capture market share, or test a hypothesis. This is closest to Cunningham's original meaning.
  • Natural entropy. Code that was correct and idiomatic at launch but is no longer aligned with current frameworks, libraries, or business logic. Nobody made a mistake; the surrounding context changed.
  • Organizational and cultural issues. Systems that languish because incentives (quarterly bonuses, feature-volume KPIs, project-shaped roadmaps) heavily favor shipping velocity over sustainable engineering. This category is the most expensive and the most often misattributed to "the code."12791011

Lumping these together hides the fact that the response to each is fundamentally different. A deliberate trade-off can be repaid. Natural entropy is managed through ongoing maintenance. Organizational dysfunction is not solved by refactoring.

Treat Trade-Offs Like Maintenance, Not a Balance

The most effective engineering organizations stop pretending there is a balance sheet to zero out and instead treat these issues as ongoing maintenance costs.45

  • Name it. Document shortcuts the moment they are made: in the code, in the PR, in a tracked location someone will actually re-read. Unnamed debt is the hardest to resolve, because no one remembers what trade-off was being made or why.
  • Assess risk by blast radius. A shortcut in an infrequently used internal tool costs almost nothing. The same shortcut in a high-traffic payment service requires immediate attention. The size of the problem is determined by where it lives, not by how ugly the code looks.
  • Pay it down where you already are. The cheapest time to improve a piece of code is when you are already changing it for some other reason. The most expensive time is during a dedicated "tech debt sprint" that ships nothing.
  • Avoid the big rewrite. Large-scale "pay off the debt" rewrites are notoriously high-risk. They almost always run long, almost always omit features the original quietly handled, and almost always produce new software that carries its own fresh set of trade-offs. Incremental change beats heroic replacement.123

What This Looks Like in Practice

A healthy engineering organization talks less about "tech debt" and more about specifics:

  • "This module is hard to change because the data model assumes a single tenant."
  • "We chose the simpler queue because we needed to ship before the trade show; here is the issue tracking the migration."
  • "Our incident rate in this area is high because the original framework is no longer maintained."

Each of these is actionable. "We have a lot of tech debt" is not.

Core principle

The question is not whether to "pay off" technical debt. The question is whether the trade-offs in your codebase are named, understood, and matched to their actual cost.

See also: Architecture Is About Change, Maintainability, Software Is Economics, Total Cost of Ownership, Further Reading.

  1. Ward Cunningham, The Debt Metaphor (2009). Cunningham's own retrospective on the metaphor he coined: https://www.youtube.com/watch?v=pqeJFYwnkjE ↩

  2. Martin Fowler, Technical Debt Quadrant. The classic four-quadrant model separating deliberate from inadvertent and prudent from reckless: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html ↩

  3. Joel Spolsky, Things You Should Never Do, Part I (2000). The canonical essay on why rewriting from scratch is the single worst strategic mistake a software company can make: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ↩

  4. Oskar Dudycz, Tech Debt Doesn't Exist, But Trade-offs Do, in Architecture Weekly: https://www.architecture-weekly.com/p/tech-debt-doesnt-exist-but-trade ↩↩↩

  5. Discussion thread, A common belief seems to be tech debt bad. What's yours?, on r/ExperiencedDevs: https://www.reddit.com/r/ExperiencedDevs/comments/rqu4wq/a_common_belief_seems_to_be_tech_debt_bad_what/ ↩↩↩

  6. Discussion thread, What's your definition of technical debt?, on r/devops: https://www.reddit.com/r/devops/comments/1qlvsg3/whats_your_definition_of_technical_debt/ ↩

  7. Short-form video on the technical-debt framing: https://www.youtube.com/shorts/M1MWNuQynuI ↩↩

  8. Shopify Engineering, Technical Debt and the 25% Rule: https://shopify.engineering/technical-debt-25-percent-rule ↩

  9. Adam the Developer, Technical Debt Is a Myth Created by Bad Managers, on dev.to: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k ↩↩

  10. Raphael Moutard, The Controversial Truth About Tech Debt, on Medium: https://medium.com/@raphael.moutard/the-controversial-truth-about-tech-debt-09ad0f787888 ↩↩

  11. Harish, Tech Debt Isn't the Problem: Corporate Culture Is, on Medium: https://medium.com/@harish852958/tech-debt-isnt-the-problem-corporate-culture-is-b4355bbfd05d ↩

  12. Doug Dockery, Technical Debt Is Not a Technical Problem, on LinkedIn: https://www.linkedin.com/posts/dougdockery_technical-debt-is-not-a-technical-problem-share-7458042343494021120-G6an/ ↩↩