Skip to content
Latticework
Esc
Try
No. 034Trade-offs & Economics

Technical Debt as Interest

Shortcuts are loans: they buy speed today and charge interest on every future change.

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”

A shortcut is cheaper today, but every later change in that code pays interest on it.

To an executive

Shortcuts buy speed now but make every later change slower and dearer. Treat them as borrowing, with interest, and decide deliberately when to repay.

To an engineer

Know which shortcuts you took on purpose and which crept in. Repay debt in areas you change often, where the interest is highest, and leave stable code alone.

The idea

Ward Cunningham introduced the debt metaphor in an experience report at OOPSLA 1992, to explain to business stakeholders why code needed refactoring. Shipping first-time code, he wrote, is like going into debt: a little debt speeds development, as long as it is paid back promptly. The danger comes when it is not.

Martin Fowler describes the interest as the extra effort it takes to change the system because of the cruft. Interest is only paid when you touch the affected area. Debt in stable, rarely changed code may never need repaying; debt in a hot path compounds with every change.

Why it works

It speaks the business's language. Executives understand loans, interest and repayment, so the metaphor turns a technical worry into a financial trade-off.

It makes shortcuts legitimate, with conditions. Taking on debt to hit a launch date can be rational, as long as the interest rate is understood and repayment is planned.

It points effort at the right places. Because interest depends on change frequency, the metaphor tells you to repay debt where the team works most, not where the code looks worst.

Where it applies

  • Portfolio and roadmap planning, where debt repayment must be funded alongside new features.
  • Application rationalisation, where high-debt, high-change systems are candidates for investment or replacement.
  • Stakeholder conversations, explaining why delivery is slowing down in a particular area.
  • Migrations, deciding which debt to fix on the way and which to leave behind with the old system.

How to apply

  1. Make debt visible: record deliberate shortcuts when you take them, with the reason.
  2. Map debt against change frequency to find where the interest is highest.
  3. Express the interest in business terms, such as days added to each change or incidents caused.
  4. Repay in high-churn areas first, as part of normal work rather than a separate rewrite.

Example scenario

A team deliberately hard-coded tax rules for one country to hit a launch date. It was a reasonable loan: the business needed to be in the market quickly.

When the business expanded to a dozen countries, each tax change took days and caused regressions. Mapping change frequency showed the tax code was the most-changed part of the system, so the interest was high. Refactoring it into a rules engine was the repayment, and it was funded because the architects could show the cost of every delayed change.

Questions to ask

  • Is this debt deliberate or accidental?
  • What interest are we paying, and how often do we change this area?
  • When and how will we repay it, and who owns that decision?

When not to use it

  • Code that is about to be retired, where repaying the debt costs more than living with it until switch-off.
  • Design disagreements, where the issue is taste rather than a measurable cost of change.

How it misleads you

Labelling every disliked design choice as "debt" to justify a rewrite. The metaphor works only when you can point to the interest: the ongoing cost each change pays. Without that, "debt" is just an opinion with a financial word attached.

In the wild

Further reading

Last reviewed · Suggest an improvement