Software Growth

Technical debt

Technical debt is the future cost of code shortcuts and outdated design, like a loan that charges interest as every later change takes longer.

Technical debt is a metaphor for the cost you take on when you ship code that is not as good as you now know how to make it. Like a loan, it lets you move fast today, and like a loan it charges interest: each later change is slower and riskier until you pay it down. Every software company has some. The question is whether you took it on deliberately and are managing it.

Where it comes from

Ward Cunningham coined the metaphor while building a financial application in Smalltalk. In his 1992 OOPSLA experience report on the WyCash portfolio system, he wrote that shipping first-time code is like going into debt. A little debt speeds development as long as it is paid back promptly with a rewrite. Every minute spent on not-quite-right code counts as interest on that debt. Years later Cunningham recorded a video reflecting on the history of the metaphor and how it has been misunderstood. The debt in his sense comes from learning: your first understanding of the problem is incomplete, and the code should be reshaped as you learn, which is different from writing sloppy code on purpose.

How Martin Fowler frames it

Fowler credits Cunningham and uses the term "cruft" for the internal quality problems that slow you down. His example: a confusing module structure makes a feature take six days instead of four, and the extra two days are the interest. He recommends paying the debt gradually, cleaning code that changes often because that is where interest accrues, and leaving stable, messy code alone. He also warns against using the metaphor to justify poor quality in the name of speed, since cruft slows you within weeks rather than months.

A rough way to size it

You cannot calculate debt exactly, but you can estimate the interest.

Using Fowler's numbers, the work takes 6 days instead of 4.

A 50% tax on every change in that area. If your team touches the area weekly, paying it down earns a return fast. If nobody touches it, leave it.

Kinds of debt

  • Deliberate: "Ship the simple version now and fix it after launch." This is the defensible kind when you track it.
  • Accidental: you did not know a better design existed, or the product changed. Normal and unavoidable.
  • Neglected: you know about the problem and never schedule the fix. This is where companies get stuck.

Managing it in a small SaaS

  • Write down each shortcut when you take it, with what would trigger repayment.
  • Reserve a fixed slice of each cycle (many teams use 10 to 20%) for cleanup in code you are already changing.
  • Use a feature flag to release in small steps, which reduces the risk of refactoring.
  • Watch for feature creep, which multiplies debt, since every extra feature is more code to maintain.

An early MVP built fast is a sensible loan. Taking more debt on a product that has proved demand, with customers waiting on reliability, is not.

Sources

Back to the SaaS glossary