Technical Debt: How to Quantify, Prioritise, and Reduce It

What Technical Debt Actually Is

Ward Cunningham's original metaphor: knowingly writing suboptimal code to ship faster, with the intention of refactoring later. The "debt" is the interest paid over time as the codebase becomes harder to change. The four categories most engineering teams face:

• Deliberate debt: Consciously chosen shortcuts — acceptable when the decision is logged and planned for payoff
• Accidental debt: Suboptimal design discovered after the fact — requires discovery and documentation
• Architectural debt: System design decisions that don't scale — the most expensive category
• Dependency debt: Outdated libraries, deprecated APIs, unpatched security vulnerabilities

How to Quantify It

Technical debt is qualitative in nature but can be approximated with measurable proxies:

• Cycle time creep: If adding a feature to System A takes 3x longer than the equivalent feature in System B, the difference is debt-related friction
• Bug rate by module: Modules with higher-than-average defect rates indicate structural debt
• Code complexity metrics: Cyclomatic complexity, cognitive complexity — tools like SonarQube generate these automatically
• Test coverage gaps: Untested code is both a debt signal and a debt accelerator
• Developer sentiment: "The areas every engineer avoids" are your debt hotspots

Prioritisation Framework

Not all debt is worth paying off immediately. Prioritise by the intersection of: frequency of change (how often does this code get touched) × carrying cost (how much does it slow each touch) × risk (what breaks if it fails).

• High change frequency + high carrying cost = pay off immediately
• Low change frequency + low carrying cost = schedule for later or accept permanently
• High risk regardless of frequency = security and compliance debt is always priority

“Shipping first and cleaning up later is not the problem. The problem is that ‘later’ never comes unless you make it non-negotiable. Every codebase reflects the organisation’s actual values, not its stated ones.”

Communicating Debt to Non-Technical Stakeholders

The breakdown point for most debt reduction programmes is not technical — it’s organisational. Engineers can identify and prioritise debt accurately, but when product managers or executives control sprint capacity allocation, debt reduction competes against feature development with no shared language for comparison. “Refactor the authentication module” loses to “add the enterprise SSO feature” every time unless the debt’s business impact is quantified in the same terms as features.

Translate debt into business language before presenting it to non-technical stakeholders. Replace “high cyclomatic complexity in the order processing module” with “every new payment method integration currently takes 3 weeks; after this refactor, it will take 3 days, saving approximately $X per integration.” Replace “outdated authentication library with known CVE” with “unpatched security vulnerability in the login system that could expose customer data and trigger GDPR notification obligations.”

Practical presentation formats that work for non-technical stakeholders: a technical health dashboard with a simple red/amber/green status per system component updated monthly, a debt-to-velocity chart showing how average sprint delivery speed has changed as the codebase has grown (debt’s fingerprint is clearly visible in velocity slowdown over time), and a “10 most expensive modules to change” list with approximate cost per change compared to baseline modules.

When to Rewrite vs When to Refactor

The rewrite decision is one of the most consequential calls in software engineering — and one of the most frequently made on the wrong basis. Martin Fowler’s recommendation is to be deeply sceptical of the big rewrite: the new system is typically built by the same team, with the same organisational pressures, and ends up accumulating similar debt within 2–3 years, while the rewrite itself typically takes 2× longer and costs 3× more than estimated.

Refactor (not rewrite) when: the core data model is sound, the domain logic is correct even if the implementation is messy, the system has known boundaries, and the team that will maintain the refactored system is the same team that built it. Rewrite when: the core data model is fundamentally broken and cannot be incrementally corrected, the technology has been sunset and security patches are no longer available, or the system’s architecture makes it impossible to add the capabilities the business now requires.

The middle path that is almost always preferable to a full rewrite is the strangler fig pattern: build the new system incrementally alongside the old, redirect specific traffic flows to the new system, deprecate the old one section by section. This approach has a much higher success rate, preserves operating continuity, and allows the team to validate the new architecture with real traffic before the old system is fully retired.

Reducing Debt Without Stopping Delivery

The key is embedding debt reduction into normal delivery cycles rather than treating it as a separate initiative that competes with features:

• The 20% rule: Reserve 20% of every sprint for debt reduction — non-negotiable, documented in team agreements and visible in velocity tracking
• The boy scout rule: Leave every file you touch cleaner than you found it — incremental improvement without dedicated sprints or stakeholder approval
• Strangler fig pattern: For architectural debt, build the new system alongside the old, gradually redirecting traffic — avoids big-bang rewrites and the risk they carry
• Dependency updates as CI: Run automated dependency update PRs via Renovate Bot or Dependabot to prevent dependency debt accumulating silently between releases
• Tech debt as backlog items: Log all known debt as ordinary backlog tickets with business-impact language so product managers can prioritise them alongside features

Technical Debt Triage Checklist

Run this checklist quarterly with your engineering lead to keep debt visible and measurable:

• All known debt items logged as tickets with impact description (not just "refactor X")
• Cycle time measured per module — identify the 20% of the codebase causing 80% of slowdowns
• Dependency audit run: flag any packages more than 2 major versions behind or with known CVEs
• Test coverage report reviewed — flag modules below 60% unit test coverage for attention
• SonarQube / code quality gate results reviewed and regressions acted on
• Sprint capacity for debt confirmed in team agreement for next quarter
• Architectural risk areas documented and shared with product owner
• Strangler fig migrations in progress reviewed for completion timeline