Tech Terms Explained Open in the app →

Technical Debt

Software Engineering · Beginner · 4 min read

What is it?

Technical debt is the future cost of choosing a quick or easy solution now instead of a better but slower one.

Explain like I'm 5

Technical debt is like borrowing money to move fast today: handy in a pinch, but you pay interest later in the form of harder, slower work.

Why was it created?

The metaphor was coined to explain to non-engineers why shortcuts taken to ship faster create real, compounding costs later.

Where is it used?

  • Planning and prioritization
  • Communicating trade-offs
  • Code reviews
  • Deciding when to refactor

Why should developers care?

Managing technical debt is a constant trade-off in real projects, and the term is essential for communicating with teams and stakeholders.

How does it work?

Every shortcut — skipped tests, rushed design, copy-paste code — makes future changes harder. Like financial debt, it accrues 'interest': the longer it's unpaid, the more it slows the team. You 'repay' it by refactoring and cleanup.

Real-world example

To hit a deadline, a team hardcodes values instead of building config; months later, every change requires editing many files — the interest on that debt.

Common use cases

  • Justifying refactoring time
  • Prioritizing cleanup
  • Explaining slowdowns
  • Balancing speed vs quality

Advantages

  • (As a concept) names a real trade-off
  • Helps communicate cost of shortcuts
  • Guides prioritization
  • Sometimes worth taking deliberately

Disadvantages

  • Slows future work if unmanaged
  • Compounds over time
  • Can hurt morale
  • Hard to quantify precisely

When should you use it?

When discussing trade-offs, planning cleanup, or deciding whether a shortcut is acceptable.

When should you avoid it?

Don't let it accumulate unmanaged; and avoid taking on debt you have no plan to repay.

Alternatives

Doing it 'right' upfront (slower now)Continuous refactoring to keep debt low

Related terms

RefactoringFeature FlagsDesign PatternsTest-Driven Development

Interview questions

Beginner

  • What is technical debt?
  • Give an example of taking on debt.

Intermediate

  • How does debt 'accrue interest'?
  • When is taking on debt reasonable?

Senior

  • How do you prioritize paying down debt?
  • How do you communicate debt to non-technical stakeholders?

Common misconceptions

  • "Technical debt is always bad" — deliberate, well-managed debt can be a smart trade-off to ship sooner.
  • "Debt is just messy code" — it's the future cost of shortcuts, which includes skipped tests, docs, and design too.

Fun facts

  • The metaphor was introduced by Ward Cunningham.
  • Like real debt, the danger is the compounding 'interest', not the loan itself.

Timeline

  • 1992 — Ward Cunningham introduces the technical debt metaphor

Learning resources

Quick summary

Technical debt is the future cost of taking shortcuts now; like financial debt it accrues interest and is repaid through refactoring.

Cheat sheet

  • Future cost of shortcuts
  • Accrues 'interest' over time
  • Repaid by refactoring
  • Sometimes worth taking deliberately

If you remember only one thing

Technical debt is the compounding future cost of shortcuts taken today — manageable, but dangerous if ignored.