Managing Technical Debt

How to Calculate the Cost of Technical Debt

SonarQube calculates remediation cost automatically by scanning code for issues and estimating the developer time required to resolve each one at a default rate of $14 per hour. A codebase scan that finds 800 hours of remediation at this rate produces a $11,200 debt figure — a number that is specific enough to include in a board presentation and compare against the cost of addressing it. This transforms technical debt from an abstract engineering concern into a business decision with a dollar value, which is the only framing that gets non-technical stakeholders to allocate time and budget for remediation.

Martin Fowler's technical debt quadrant provides a more nuanced model by crossing two axes: deliberate vs inadvertent, and reckless vs prudent. Deliberate-reckless debt is "we don't have time to write tests" — a choice made in full awareness that creates future cost. Deliberate-prudent debt is "we'll ship now and document the trade-off for refactoring next quarter" — a strategic decision with a known plan. Inadvertent-reckless debt is code written by someone who did not know best practices — fixable through training. Inadvertent-prudent debt is "we only realised this was the wrong architecture after building with it" — unavoidable learning cost. Each type has a different appropriate response; treating all debt as equivalent produces intervention strategies that misfire.

Refactor vs New Feature Tradeoff

The 20 percent rule allocates 20 percent of every sprint's engineering capacity to technical debt repayment and refactoring work, with the remaining 80 percent available for new features. Both Google and Atlassian have documented using this ratio as a structural policy rather than leaving debt work to engineering discretion. Without a structural allocation, debt repayment never happens in practice: every sprint planning session produces urgent feature requests that collectively occupy 100 percent of available capacity, and "we'll clean that up next sprint" becomes a deferral that compounds across quarters.

Kent Beck's rule of three provides practical guidance for when individual refactoring is warranted outside the 20 percent allocation: refactor when you touch the same code for the third time. The first time you write code, write it. The second time you modify the same section, note the duplication. The third time you are in the same code, stop and refactor it before continuing. This heuristic prevents both premature refactoring — which is itself a waste of engineering time — and indefinite deferral of necessary structural improvement. The Boy Scout Rule complements it at the commit level: leave any code you touch slightly cleaner than you found it, which distributes small quality improvements across the codebase continuously rather than in a single large refactoring initiative.

Protecting Engineering Time

Technical debt compounds in teams under constant feature pressure because every shortcut taken reduces the speed of the next feature delivery, which creates more schedule pressure, which incentivises more shortcuts. Stripe's internal research found that engineering teams with high technical debt report approximately twice the voluntary turnover rate of teams with low technical debt. This creates a second-order cost that never appears in a debt calculator: experienced engineers who understand the codebase leave, institutional knowledge departs with them, and new engineers inherit a codebase they did not build and cannot navigate quickly.

The practical protection is a sprint planning rule that treats debt repayment tickets with the same priority mechanism as feature tickets. Debt tickets go through the same RICE scoring or equivalent process, receive story points, and are included in the sprint commitment at the 20 percent allocation. When a feature ticket displaces a debt ticket, the debt ticket rolls forward to the next sprint and increments a visibility counter. After three consecutive deferrals, the ticket escalates to a discussion in the retrospective — this visibility mechanism prevents debt work from silently accumulating in the backlog indefinitely while creating the stakeholder awareness needed to protect the allocation.

Maintaining a Debt Inventory

A debt inventory is a living document listing every known technical debt item with four fields: location (file, module, or system), nature (code smells, architectural mismatch, missing tests, dependency version), estimated remediation effort (hours), and business impact (performance degradation, security risk, feature velocity drag, or developer experience). The inventory does not need to be exhaustive from day one — it should be seeded from the first SonarQube scan and populated incrementally as engineers encounter debt in the course of normal feature work.

The debt inventory serves two functions: it makes the aggregate cost visible at the portfolio level, and it provides a prioritised input for the 20 percent sprint allocation. Without an inventory, debt repayment work is ad hoc and concentrates on whatever the most vocal engineer happens to dislike, rather than on the debt that is most directly slowing feature delivery or creating reliability risk. With an inventory sorted by estimated impact on feature velocity, the team can direct the 20 percent allocation to the items that are most directly costing them speed — which is the only argument that consistently wins sprint planning prioritisation discussions against competing feature requests.

Frequently Asked Questions

How does SonarQube calculate technical debt cost? SonarQube scans code for issues and estimates developer remediation time at a default rate of $14 per hour. The total scan result produces a dollar figure representing the cost to resolve all identified issues, making debt visible as a business cost rather than only an engineering concern.

What is Martin Fowler's technical debt quadrant? A two-axis model crossing deliberate vs inadvertent debt with reckless vs prudent debt. Each of the four quadrants requires a different response — from strategic planning for deliberate-prudent debt to training for inadvertent-reckless debt. Treating all debt identically produces mismatched interventions.

What is the 20% sprint rule for technical debt? Allocating 20 percent of every sprint's engineering capacity to technical debt repayment and refactoring. Both Google and Atlassian use this as a structural policy. Without a fixed allocation, urgent feature requests fill 100 percent of capacity every sprint and debt work never happens.

What is Kent Beck's rule of three for refactoring? Refactor when you touch the same code section for the third time. Write it the first time, note duplication the second time, and stop to refactor before continuing on the third encounter. This prevents both premature refactoring and indefinite deferral.

Why does technical debt cause engineer turnover? Stripe's internal research found teams with high technical debt have approximately twice the voluntary turnover rate of low-debt teams. Engineers who find code unmaintainable, slow, or frustrating to work with leave for environments where they can be effective. The institutional knowledge cost of that turnover often exceeds the original cost of the debt.