“Technical debt” is used to mean two quite different things, and conflating them is why the conversation with finance goes badly.
The original metaphor described a deliberate trade: ship now with a design you know is imperfect, accept that future changes cost more, and repay when it makes sense. That’s a reasonable business decision, taken knowingly.
The word is now more often used for accumulated mess — code nobody understands, dependencies years out of date, a test suite that fails intermittently and gets ignored. That isn’t a considered trade. It’s deferred maintenance.
Both slow you down. Only one was a decision. And neither is automatically worth fixing.
Interest rate, not ugliness
The only property that matters is the interest rate: how much does this cost you, per month, in real terms?
Ugly code in a module nobody touches has an interest rate near zero. It offends engineers and costs nothing. Leave it.
A fragile deployment process that adds two hours to every release and causes a rollback each month has a very high rate. It compounds, because it also discourages small releases, which makes each release larger and riskier.
Estimate the rate in the units your organisation cares about:
- Extra engineer-hours per change in that area
- Incidents per quarter attributable to it
- Delay to a feature the business wants
- Onboarding time lost to it
- Risk exposure — unsupported dependencies, unpatched security issues
Then rank. Most teams find three or four items account for most of the cost, and a long tail of irritations account for almost none.
Debt worth paying down almost always
Anything blocking safe, frequent deployment. Manual releases, no rollback, flaky pipelines. This is the highest-leverage item in most systems, because everything else depends on it.
Tests you don’t trust. An unreliable suite is worse than none: it costs time and teaches people to ignore failures. Either fix it or delete the parts that lie.
Unsupported dependencies with known vulnerabilities. The rate looks like zero until it’s catastrophic. This is insurance, not optimisation.
Anything in the path of the next six months of roadmap. Debt in code you’re about to change heavily is expensive right now.
Single points of knowledge. One person understanding the billing system is an operational risk, not just a code problem.
Debt worth living with
Ugly but stable code that rarely changes. Zero rate. Leave it.
Old technology that still works and is supported. Being unfashionable isn’t a defect. Rewriting a working system in a newer framework because engineers prefer it is a cost with no return.
Duplication that hasn’t yet caused a bug. Premature abstraction causes more problems than duplication does. Wait until the third occurrence.
Anything in a component you plan to retire. Don’t renovate a building you’re demolishing.
Inconsistency that’s purely cosmetic. Formatting and naming differences are worth a linter, not a project.
How to fund it
The request that fails is “we need a sprint for refactoring.” It sounds like engineers prioritising their comfort, and it’s the first thing cut when a date is at risk.
Approaches that work:
Attach it to the feature. When work touches an area, improve that area as part of the estimate. No separate conversation, no separate approval. The main risk is scope creep — constrain it to what the change genuinely needs.
Express it in business terms. Not “the payments module is badly structured” but “changes to payments take three times longer than elsewhere, and we have four payment changes planned this year — this work pays for itself by the third.” That’s a case a finance director can evaluate.
Use incidents as evidence. After an outage caused by known debt, the case is easier and the window is short. Have the proposal ready before you need it.
Reserve a standing percentage. Some teams protect 15–20% of capacity for maintenance, agreed once rather than negotiated repeatedly. This works when trust is high and fails when the work isn’t visible — so report what it bought.
Make it visible. A short list of the top five items with estimated monthly cost, reviewed quarterly with the business, converts an abstract complaint into a managed backlog.
A practical triage
For each candidate:
- What does it cost per month, roughly, in hours or incidents?
- Is it in the path of planned work?
- What’s the risk if we do nothing for a year?
- How long would remediation take, honestly?
- Can it be done incrementally, or does it need one large change?
High cost, in the roadmap’s path, and incrementally fixable → do it now, inside feature work. High risk, low frequency of change → schedule it deliberately, treat it as insurance. Low cost, not in the path → document it and move on. Writing it down is enough; not every known problem needs a plan.
The debt worth taking
It’s worth remembering the metaphor cuts both ways. Deliberately taking on debt is sometimes right: to hit a market window, to validate an idea before investing properly, to get a customer live. The failure isn’t taking it — it’s taking it without recording the decision, so nobody knows later that a shortcut was chosen, why, and under what conditions it should be revisited.
A one-paragraph note in the repository at the moment of the decision costs nothing and saves an argument two years later about whether the code was a mistake or a choice.
Frequently asked questions
How much technical debt is normal? Every system in active use has some. Volume matters less than whether the expensive items are known and managed.
Should we stop features to fix debt? Rarely, and only for genuine risk — a security issue or an unsupportable dependency. Otherwise attach remediation to feature work, which is both more palatable and more targeted.
How do we stop it accumulating? Code review with real standards, an honest definition of done, and time in estimates for doing things properly. Most debt accumulates through repeated small omissions, not one bad decision.
Is rewriting ever the answer to debt? Occasionally, for small components. For whole systems, incremental replacement is almost always the better bet — see the modernisation guide for how that’s sequenced.
Internal links: #17 legacy modernisation, #7 MVP cost. External references: Ward Cunningham’s original framing of the debt metaphor; Martin Fowler’s technical debt quadrant for distinguishing deliberate from inadvertent debt. CTA: “Want an outside read on which debt is actually costing you? We do short technical assessments.” → /contact