Technical Debt in Software: How to Measure, Manage and Pay It Down

Key Takeaway

Technical debt costs the average enterprise $3.6M annually in lost productivity and system failures. The three most common sources are MVP code rushed into production and never cleaned up, deferred dependency and security updates, and missing automated test coverage. The right response is not a big-bang rewrite — it is systematic measurement, prioritisation, and dedicated paydown capacity (the 20% rule: allocate 20% of every sprint to debt reduction).

What Is Technical Debt?

Technical debt is the implied cost of future rework caused by choosing an expedient solution now instead of a better approach that would take longer. Ward Cunningham coined the term in 1992 — the metaphor is financial debt: you borrow time now and pay it back later, with interest.

The interest is real: a shortcut taken under deadline pressure in Q1 can cost 5x the time to fix in Q3, because by then other code has been built on top of it.

Technical debt is not always bad. Choosing to ship an MVP with known shortcuts is often the right business decision. The problem is when the debt is never acknowledged, never measured, and never repaid.

The 4 Types of Technical Debt

Martin Fowler's Technical Debt Quadrant maps debt across two dimensions: deliberate vs. inadvertent, and reckless vs. prudent.

Type	Description	Example	Response
Deliberate + Prudent	Knowingly took a shortcut with a plan to fix it	"We'll hard-code this for now and refactor after launch"	Schedule and execute the refactor
Deliberate + Reckless	Knowingly cut corners without a plan	"We don't have time for tests"	Dangerous — add tests before adding features
Inadvertent + Prudent	Good practice at the time, now outdated	Code written before modern async patterns existed	Refactor as you touch the area
Inadvertent + Reckless	Did not know it was a problem when written	Junior dev unknowingly created N+1 query loops	Identify, measure impact, fix in priority order

Most enterprise codebases have all four types. The deliberate + reckless and inadvertent + reckless types are the highest priority to address.

How to Measure Technical Debt

You cannot manage what you cannot measure. These metrics give you a quantitative view of debt:

Bug density: Bugs per 1,000 lines of code. Above 5 bugs/KLOC indicates systemic quality problems. Industry average is 1–5 bugs/KLOC; mature codebases target under 1.

Code coverage: Percentage of code exercised by automated tests. Below 40% is a risk indicator. Targeting 70%+ for core business logic is a realistic goal for most codebases.

Deployment frequency: How often you can ship to production. If your team deploys less than once per week, the deployment process itself is likely a source of debt (manual steps, insufficient automation, fear of breakage).

Mean time to recovery (MTTR): How long it takes to restore service after an incident. High MTTR signals insufficient monitoring, complex rollback procedures, or fragile infrastructure — all debt indicators.

Cyclomatic complexity: A code-level metric measuring the number of independent paths through a function. Functions above 15 are hard to test and hard to change without breaking things. Tools like SonarQube measure this automatically.

Dependency age: How many of your third-party dependencies are more than 2 major versions behind. Each lagging major version is a security risk and a future migration cost.

The Real Cost of Ignoring Technical Debt

Consequence	Measurable Impact
Slower feature delivery	Teams with high debt ship 2–4x fewer features per sprint than teams with clean codebases
Higher bug rate	High-debt codebases have 3–5x more production incidents than maintained ones
Developer attrition	Engineers leave codebases they cannot be proud of — debt contributes to 30% of voluntary attrition
Security exposure	Outdated dependencies account for 60%+ of exploited vulnerabilities
Onboarding cost	New engineers take 3–4 months to become productive in high-debt codebases vs 4–6 weeks in clean ones
Infrastructure cost	Technical debt in architecture (monoliths that should be services, synchronous calls that should be async) drives unnecessary cloud spend

McKinsey research found that in high-debt engineering organisations, 10–20% of what should go to new features actually goes to managing existing technical debt.

7 Strategies to Pay Down Technical Debt

1. The 20% rule. Allocate 20% of every sprint — one day per developer per week — to debt reduction. This is the most sustainable approach. It prevents accumulation, maintains momentum, and does not require a big-bang modernisation project.

2. The Boy Scout Rule. Leave every piece of code you touch cleaner than you found it. Not a major refactor — just one small improvement per visit. Consistent application across a team has a significant cumulative effect over 6–12 months.

3. Debt sprints. One sprint per quarter dedicated entirely to technical debt reduction. Works best for teams that struggle to context-switch between feature work and debt work within the same sprint.

4. Test coverage as a gate. Require that every new feature ships with tests covering its core paths. Do not allow the test coverage metric to go down. This stops new debt from accumulating even while you pay down existing debt.

5. Dependency update automation. Use Dependabot (GitHub) or Renovate to automatically create pull requests for dependency updates. Review and merge weekly. This eliminates dependency debt accumulation almost entirely.

6. Module-by-module refactoring. Rather than refactoring the whole system, identify the highest-debt modules (typically the ones that have the most bugs and the most churn) and refactor one at a time. Measure impact before and after.

7. The Strangler Fig for architecture debt. For systems with architectural debt (monoliths that need to be services, synchronous processes that need to be async), use the Strangler Fig pattern — build the new architecture alongside the old one, migrating feature by feature, rather than a risky big-bang rewrite.

When to Modernise vs When to Rebuild

Modernise (refactor) when:

• The core data model is sound and worth preserving
• The business logic is correct, just poorly structured
• A 4–6 month refactoring project would resolve the major pain points
• The system has enough test coverage to refactor safely

Rebuild when:

• The technology stack is obsolete and cannot be incrementally updated
• The data model has fundamental design problems that refactoring cannot fix
• Developer productivity has collapsed and the codebase is demoralising the team
• Security vulnerabilities are so deep that patching is less effective than rebuilding

The most common mistake is choosing "rebuild" too early. A full rebuild typically costs 3–5x what most CTOs estimate, takes twice as long, and risks replicating the same design mistakes in the new system.

How Ortem Handles Tech Debt in Client Projects

When Ortem takes on existing codebases, we start with a technical audit: we measure code coverage, dependency age, cyclomatic complexity, deployment frequency, and MTTR. We produce a debt register — a prioritised list of debt items with effort and impact estimates — and include debt reduction in the project scope from week one.

We do not allow clients to add features on top of unaddressed critical debt. A crumbling foundation does not improve by adding another floor.

Discuss a technical assessment → | Custom software development →

FAQ

Q: How much technical debt is acceptable? Some debt is always acceptable — perfect code is an unrealistic standard that slows delivery. The right question is: "Is our debt level trending up or down, and is it at a level that allows us to deliver value at the pace the business needs?" If your team's velocity is declining quarter over quarter, your debt level is too high.

Q: Who is responsible for managing technical debt? Engineering leadership owns the measurement and prioritisation. Product management owns the trade-off decisions (debt reduction vs new features). Executive leadership owns the resource allocation. Technical debt is a business problem, not just an engineering problem — it affects delivery speed, reliability, and cost.

Q: Can you quantify technical debt in dollars? Approximately. SonarQube estimates "remediation cost" in developer hours. Multiply by your blended developer rate to get a dollar figure. This is directionally useful for prioritisation but not precise — it measures the cost to fix, not the cost of keeping it.

Q: Is it ever too late to address technical debt? If the system is still in production and business-critical, it is never too late — but the options narrow. Early-stage debt gives you all six strategies. Late-stage debt in a business-critical system usually leaves you with the Strangler Fig pattern or a high-risk rewrite.

---

Dealing with a codebase that is slowing your team down? Ortem Technologies' custom software team has taken on codebases with significant technical debt and systematically restored development velocity. Book a technical assessment → | Related: Legacy system modernization → | Custom software development approach →