Every software system accumulates technical debt. It is an inevitable consequence of making pragmatic decisions under time and resource constraints. The question is not whether your codebase has technical debt, but whether you are managing it deliberately or allowing it to compound unchecked. Through our consulting work, we have developed a framework for measuring technical debt and making rational decisions about when to pay it down.
We categorise technical debt into three types. Deliberate debt is taken on consciously, with a plan for repayment. A team might choose a quick implementation to meet a deadline, with a ticket already created for the proper solution. Accidental debt arises from gaps in knowledge or changing requirements. What was a good design decision two years ago may be debt today because the system has evolved. Bit rot is the gradual degradation that occurs when dependencies are not updated, tests are not maintained, and documentation falls behind.
Technical debt is not inherently bad. Unmanaged technical debt is catastrophic.
Measuring technical debt requires a combination of automated metrics and human judgement. Static analysis tools can measure cyclomatic complexity, code duplication, and dependency age. These provide useful trend data but do not capture the full picture. The most valuable metric we track is change failure rate: the percentage of deployments that cause an incident. High change failure rates indicate that the codebase has become difficult to modify safely, which is a direct measure of technical debt's impact on delivery.
A Framework for Prioritisation
Not all debt requires immediate repayment. Debt in code that rarely changes and works reliably is low priority regardless of how messy it looks. Debt in code that your team modifies frequently and that causes bugs or slows development is high priority. We use a simple scoring matrix: frequency of change multiplied by impact severity. High-change, high-impact modules get addressed first. Low-change, low-impact modules may never need refactoring.
- Categorise debt as deliberate, accidental, or bit rot to inform your approach
- Track change failure rate as a proxy for technical debt impact
- Prioritise debt in frequently-changed, high-impact modules first
- Allocate a consistent percentage of each sprint to debt repayment (we recommend 15-20%)
- Frame debt repayment in business terms: delivery speed, incident reduction, team retention
Making the business case for debt repayment requires translating technical metrics into business language. Rather than telling stakeholders that your cyclomatic complexity score is too high, explain that the payment processing module takes three times longer to modify than it should, which delays every feature that touches billing. Frame debt repayment as an investment in delivery speed, not as a cost of cleaning up past mistakes.
