What is technical debt?
The same feature that took a week last year now takes a month, and no single person can point at what changed.
Technical debt
Tech debtCode debtDesign debt
Technical debt is the future cost of choosing a quicker way to build something now instead of a better way. Like a loan, it is repaid with interest: each shortcut makes the next change slower and riskier until someone goes back and fixes it.
Ward Cunningham coined the term in 1992, and the metaphor was deliberate. Borrowing can be a smart move. Never repaying is what ruins you.
Four kinds show up in real codebases. Code nobody wants to touch. Libraries and runtimes years behind their current release. A data model that no longer matches how the business works. And missing tests, which is the debt that makes repaying all the others dangerous.
Deliberate debt is a decision: ship the simple version now, note what was skipped, come back. Accidental debt is what accumulates when nobody wrote the note.
You feel it as a schedule problem first
Debt rarely announces itself as debt. It arrives as estimates that keep growing, releases that need a weekend, and a team that hedges every answer about how long something will take.
The compounding is what makes it serious. Each shortcut narrows the safe path for the next change, so the cost per feature rises even though the team has not got worse. That is why adding people to a heavily indebted codebase often slows delivery further.
Not all of it is worth repaying. Code that works, never changes and is walled off behind a stable interface can stay ugly for years at no cost. Debt only bills you where the work is.
- 01Measure it where it hurts: how long a small change takes from request to production.
- 02An out-of-support dependency is a security problem before it is an engineering one.
- 03Missing tests are the debt to repay first, because they are what makes repaying the rest safe.
- ShortcutShip now, fix later.
- SpreadOthers build on top of it.
- SlowEach change costs more.
- FearNobody wants to touch it.
- FreezeRewrite gets proposed.
The fourth station is the expensive one. Once a team is afraid of a file, the cost stops being technical.
Common questions
01Is technical debt always bad?
No, and treating it that way leads to over-engineering. Shipping a simpler version to learn whether anyone wants the feature is often the correct call, and the debt is the price of that answer. What separates good debt from bad is whether it was chosen on purpose and written down.
02How do we explain technical debt to a board?
Translate it into delivery time and risk, since those are the terms a board already uses. A small change taking three weeks instead of three days is a number anyone can act on. So is a payment library that no longer receives security patches.
03How much time should a team spend paying it down?
Enough that delivery time stops getting worse. Many teams reserve a slice of every cycle rather than running occasional cleanup projects, because a scheduled sprint of repayment competes with features and loses. Tie the work to the areas you are about to change anyway.
04Does AI-generated code create technical debt?
It can, and faster than hand-written code does. A model produces plausible code quickly, so volume goes up while review capacity stays flat, and unreviewed code is unowned code. The control is unchanged: the same review, the same tests, the same person accountable for the file.
