Technical Debt Metrics Vocabulary — Code Quality Exercises

1 / 5

In an architecture review, a tech lead says: "The SonarQube report shows our technical debt ratio is 18%. That means it will take roughly 18% of the original development investment to clean this codebase up to a maintainable baseline. We're in the 'C' band — we should be targeting 'A'." What does a debt ratio of 18% mean operationally, and what is the 'A' band target?

The SQALE debt ratio expresses the total cleanup cost of a codebase as a proportion of its estimated development cost — turning an abstract quality score into an engineering-time estimate that leadership can understand and budget for.

SQALE maintainability rating:

Rating	Debt ratio	What it means
A	≤ 5%	Maintainability in excellent shape
B	6–10%	Small debt — manageable with routine hygiene
C	11–20%	Significant debt — proactive remediation needed
D	21–50%	High debt — serious maintenance burden
E	> 50%	Extreme debt — potentially untestable/unmaintainable

Path from C to A — highest-leverage actions:
① Remove duplicated code blocks (SonarQube often assigns 30–60 min per duplication violation)
② Reduce cognitive complexity in the highest-scoring functions
③ Fix naming violations and magic numbers (fast wins; many small issues add up)
④ Set a new-debt quality gate: prevent the ratio from increasing while old debt is paid down

Reporting language:
• "At 18% debt ratio, we're about 180 developer-days of remediation work from a clean codebase."
• "Our target is the A band — below 5% — which would require approximately 130 days of focused remediation."
• "If we allocate 10% of each sprint to debt remediation, we can reach the A band in about 18 months."

Key vocabulary:
• Debt ratio — remediation cost ÷ estimated development cost, as a percentage
• SQALE rating — SonarQube's A–E maintainability grade derived from debt ratio
• Remediation cost — the estimated developer time needed to fix a specific code issue
• Debt band — a named category of debt ratio ranges (A through E) with associated risk levels

2 / 5

A developer presents a technical debt item to the product manager: "This function has no unit tests, duplicated logic, and a cyclomatic complexity of 28. SonarQube estimates it will take 4.5 hours to fix the associated issues. But the real cost is the interest we're paying — every feature we add to this module takes twice as long as it should because of the existing mess." What does the "interest" metaphor communicate, and why is it persuasive for non-technical stakeholders?

3 / 5

During sprint planning, the engineering manager says: "Let's review the technical debt backlog. I want to prioritise items based on cost to fix vs. cost of delay — not just by how annoying they are to live with." What is a technical debt backlog, and what does "cost of delay" mean in this context?

Prioritising technical debt by "cost of fix vs. cost of delay" is a data-driven approach that treats debt remediation decisions with the same economic rigour as feature prioritisation decisions.

The two-dimensional prioritisation framework:

Quadrant	Cost to fix	Cost of delay	Action
High value	Low	High	Fix immediately — best ROI
Invest carefully	High	High	Schedule a dedicated remediation sprint
Low priority	Low	Low	Fix opportunistically (boy scout rule)
Leave alone	High	Low	Rarely touched; not worth the risk of change

Signals of high cost of delay:
• The debt is in a file that is modified frequently (high churn)
• The debt is blocking a planned feature or architecture change
• The debt is in a security or compliance-critical area
• The debt is causing recurring on-call incidents
• The debt is making onboarding new team members significantly harder

Technical debt backlog item structure (best practice):
• Description of the issue and which files are affected
• Estimated fix time (from SonarQube or team estimate)
• Cost of delay rationale: why does this need to be fixed now vs. later?
• Expected outcome: what improves after this debt is resolved?

Key vocabulary:
• Technical debt backlog — a curated list of known debt items prioritised for future remediation
• Cost of delay — the ongoing business and productivity cost of not fixing a debt item
• Boy scout rule — leaving the codebase slightly better than you found it; cleaning up small debt opportunistically
• Remediation ROI — the ratio of productivity gain to fix cost; used to prioritise debt items

4 / 5

A CTO presents to the board: "We've identified three categories of technical debt in our platform: deliberate debt we took on knowingly to hit last quarter's launch deadline, inadvertent debt from code written before we had code review standards, and bit rot — code that was fine when written but has become outdated as dependencies and practices evolved." Why is distinguishing between these three categories important for remediation planning?

The technical debt taxonomy (deliberate, inadvertent, bit rot) was developed to help teams recognise that different debt types require fundamentally different responses — the same remediation approach does not work for all three.

The three debt types in detail:

Type	Origin	Prevention	Remediation
Deliberate	Intentional shortcut taken knowingly	Track and repay explicitly; don't let it become inadvertent	Schedule before next build in same area
Inadvertent	Poor code quality without awareness	Linting, code review standards, training	Address through quality gate improvements and team practices
Bit rot	Good code made obsolete by time	Dependency management process; regular update sprints	Planned modernisation sprints; strangler fig pattern

Why this categorisation matters to stakeholders:
• Deliberate debt has a clear repayment commitment — the board can hold engineering accountable to a timeline
• Inadvertent debt reveals process gaps — prevention investment is the right response, not just cleanup
• Bit rot is predictable and preventable — regular "maintenance sprints" catch it before it becomes critical

Communication language for board presentations:
• "Our deliberate debt from Q3 is fully inventoried — we've scheduled 6 weeks of repayment in Q1."
• "The inadvertent debt reflects a period before we had code review standards — we've since implemented linting and mandatory reviews."
• "Bit rot in the authentication layer will be addressed in a modernisation sprint before the v4.0 release."

Key vocabulary:
• Deliberate debt — a known, intentional trade-off accepted to meet a deadline; should be documented and scheduled for repayment
• Inadvertent debt — poor quality code created without awareness; prevented by improving team practices
• Bit rot — previously correct code that has become outdated as the ecosystem around it evolved
• Strangler fig pattern — incrementally replacing a legacy system by building new functionality around it

5 / 5

An engineering manager proposes a new policy to the team: "We're introducing a 20% debt budget — every sprint, 20% of capacity is ring-fenced for technical debt remediation. This is not optional and it's not negotiable with product. The goal is to stop debt from compounding." What does "debt compounding" mean, and why does ring-fencing capacity prevent it?

Technical debt compounding is one of the most important and least understood dynamics in software engineering — it explains why ignored debt becomes exponentially more expensive over time.

How debt compounds:
① Feature A is built on top of poorly structured Module X (existing debt)
② Feature A is harder to implement, takes longer, and introduces new code smells — adding new debt
③ Feature B is built on top of Module X and Feature A — inheriting debt from both
④ Each subsequent feature that touches this area carries the full weight of all accumulated debt
⑤ The codebase becomes progressively harder to modify, test, and extend — velocity declines over time

Why ring-fencing debt capacity works:
• Without a protected budget, debt remediation is always de-prioritised when sprint capacity is under pressure
• A fixed allocation (20%) makes debt repayment a non-negotiable structural commitment rather than an aspiration
• Continuous small debt payments prevent large accumulations that require expensive heroic remediation efforts
• The 20% investment typically returns 30–50% in improved delivery velocity for features touching the cleaned-up areas

Negotiating the debt budget with product:
• "Without 20% debt budget, we're borrowing velocity from our future selves at compound interest."
• "The 20% debt investment will deliver a net velocity increase of 30% within two quarters."
• "We can show you the correlation: sprints with no debt work have higher velocity short-term but higher defect rates the following sprint."

Key vocabulary:
• Debt compounding — the process by which existing debt makes new features more complex, generating additional debt
• Debt budget — a ring-fenced portion of sprint capacity allocated to technical debt remediation
• Ring-fenced — allocated for a specific purpose and protected from reallocation to other priorities
• Velocity tax — the recurring slowdown in feature delivery caused by accumulated technical debt