Your team shipped one feature a week and now takes three for the same work. The cause is technical debt accumulated sprint by sprint, decision by decision, until delivery cost passed the point where anyone remembers where the problem started.
Ward Cunningham's metaphor
Ward Cunningham introduced the idea in 1992 in the WyCash system report: take the simple solution now and pay the time back later, with interest, through refactoring. Good debt exists and earns its return when the product grows.
Most of the debt you carry came by accident. Nobody ordered it. It arrives through a rushed decision, a deadline with no follow-up, or code nobody touched for three years.
Three types show up at work:
- Deliberate debt: "We ship it this way and fix it later." Later rarely comes.
- Inadvertent debt: the right design shows up only after the code is done, and the team corrects it when the schedule allows.
- Entropic debt: the system runs and nobody knows why. The documentation disappeared, the author left, the team avoids the module.
Entropic debt sits on no backlog. It collects payment when something breaks, and the bill arrives with investigation attached. Michael Feathers describes the module nobody touches in Working Effectively with Legacy Code (Prentice Hall, 2004).
Where debt takes your velocity
Three triggers do the work. An engineer reads a complex system before changing it and loses days to the path. A change in module A breaks module B, because the modules talk through side effects. Nobody volunteers the change that might take production down, and the decision queue grows.
In practice, the team spends three weeks finding where the feature plugs in and two more making sure nothing around it broke.
The curve is familiar: velocity high in the first months, a drop every quarter without investment in quality. After two or three years, new features carry so much stabilization work that the product stalls. Forsgren, Humble, and Kim measure the effect in Accelerate (2018): fast delivery tracks deploy automation, reliable tests, and planned quality work.
Technical debt belongs to the business
A CTO who files debt under engineering loses the budget conversation. The direct cost lands in five places:
- Engineering hours per feature shipped
- Production bugs and the cost of fixing them
- Engineers who leave rather than maintain a bad system
- Slow response to market openings
- Bigger incidents as the system grows fragile
Turn each line into hours and money, and the conversation with leadership changes.
Three ways to measure what you owe
Pain point map
Ask the team which area they dread touching. The answers mark the modules already costing you. An area every engineer avoids is an area carrying active debt.
Cycle time by area
Compare average delivery time across each part of the system. The section that takes three times as long is where the team loses days on every request.
Bugs by module
A module with above-average bugs usually carries high coupling and low test coverage. Raise coverage on that module before refactoring the rest.
What to pay first
Debt in a legacy system nobody uses stays parked. Debt in the API that handles 80% of your volume moves to the front, whatever it costs.
Reserve 15% to 20% of engineering capacity for refactoring, testing, documentation, and dependency upgrades. The reserve runs in every sprint; a one-off project does not move the curve. Martin Fowler treats the continuous practice in Refactoring, 2nd edition (Addison-Wesley, 2018).
Teams that skip the reserve reach a rewrite project in 18 to 24 months, with scope and timeline underestimated.
Assessment before any refactoring
When delivery has dropped and accumulated complexity is the suspect, you order an honest assessment: how much debt exists, where it sits, what it costs to carry, and what it costs to fix.
The assessment returns a number, debt in money by area. With the number on the table, you decide what you pay this quarter and what waits for the next.
