Technical Debt: A Loan With Interest and a Repayment Plan
Technical debt is the future cost of a shortcut. Naming it, pricing it, and scheduling repayment keeps it a tool rather than a slow failure.
Definition
Technical debt is the accumulated cost of design or implementation choices that make future change slower or riskier, incurred deliberately for speed or accidentally through neglect, and repaid by refactoring, replacement, or removal.
Context and scope
Every team carries debt; the difference between healthy and harmful debt is whether it is visible, owned, and paid down before interest compounds.
Common misconceptions
- Debt equals bad code — some debt is a deliberate, valuable trade
- Rewrites repay debt — rewrites often trade known debt for unknown debt
- Debt only slows feature work — it also raises incident rate and onboarding time
Anti-patterns
- Tracking debt in a backlog nobody prioritizes
- Using debt as an excuse to avoid shipping
- Refactoring without measuring whether change cost improved
Related concepts
Authoritative source
A loan, not a moral failure
The debt metaphor is financial on purpose: you borrow time now and pay interest later in slower changes, more defects, and harder onboarding. Borrowing can be the right decision before a launch or a funding round. The failure mode is borrowing without recording the loan, so nobody knows the balance until the interest becomes unpayable.
Deliberate and accidental
Deliberate debt is a conscious trade: ship a hardcoded list this quarter, replace it when the configuration service lands. Accidental debt comes from ignorance, changing requirements, or time pressure that nobody acknowledged. The first is manageable because it has a rationale and a trigger for repayment; the second is invisible until it hurts.
Making it visible and priced
Write debt items down with the decision, the cost of leaving it, and the trigger for fixing it. Price the interest in concrete terms: this module adds two days to every feature touching billing, this workaround causes one incident per quarter. A number, even an estimate, moves the conversation from taste to priority.
Repayment strategies
Pay down debt continuously in small slices, allocate a fixed share of each iteration, or schedule a dedicated effort when interest crosses a threshold. For example, a team that budgets twenty percent of every sprint for debt reduction can often avoid the rewrite that would otherwise arrive in two years. Whatever the mechanism, measure whether change lead time improves; refactoring that does not reduce future cost is just churn.
Compared to a rewrite
A rewrite promises a clean slate and delivers unknown risk: years of behaviour encoded in the old system is easy to discard and expensive to rediscover. Incremental repayment, guided by the strangler pattern, usually beats a big rewrite. The exception is a system so constrained that no incremental path exists, which is rarer than rewrite proposals claim.