Debt Interest Rate

The debt metaphor is usually invoked and rarely used. Its useful half is that debt has an interest rate (what it costs per unit time) and a principal (what it costs to fix), and the two are independent.

High interest and low principal is the obvious priority and holds most of the available value. High interest and high principal is a strategic decision. Low interest and low principal is the tempting distraction — cheap, satisfying, and worth almost nothing. Low interest and high principal should be documented and left alone.

Why it matters

Debt lists are usually sorted by how unpleasant the code is, which correlates poorly with interest rate. A module untouched for four years has an interest rate near zero however unpleasant it looks, and change history is the evidence — available in minutes and rarely consulted.

Implementation patterns

• Estimate interest from change history and incident history: how often is this touched, how long does a change take, how often does it break.
• Include the delivery tax, which is the largest component: work slowed or not attempted because the area is risky.
• Look for the under-recognised categories, which are systematically absent from debt lists:
• Missing tests on frequently-changed code — high interest, because it taxes every change.
• Slow feedback loops — build, test suite, deployment — taxing every change by every engineer and compounding across the team.
• Knowledge concentrated in one person, which is a risk with a deadline set by their departure.
• Operational debt — manual processes, missing alerts, unexercised runbooks. Frequently the highest interest rate in the estate and rarely on the list, because it is not code.
• Fund it through a protected allocation rather than per-item negotiation, owned by the team because they hold the information about where the interest actually is.

Industry example

Subscription-billing platforms such as Chargebee illustrate the asymmetry: the invoice-generation core changes rarely and carefully, so unpleasant code there has low interest; the dunning and integration surfaces change constantly, so friction there taxes every week's work. The visible ugliness and the actual cost are in different places, which is the general case rather than a peculiarity.

Failure scenarios

• Sorting by unpleasantness, spending effort where nothing changes.
• Ignoring operational debt, which is usually the highest-interest category.
• Per-item negotiation, which loses every comparison against a feature with a named customer.
• No estimate of the delivery tax, so the largest component is invisible.
• Treating all debt as needing repayment, when documenting and living with the low-interest items is correct.

Trade-offs

Estimating interest rates is imprecise and can become an analysis exercise that costs more than the fixes. The mitigation is that rough is sufficient: distinguishing "this taxes us weekly" from "this taxes us never" requires no precision and captures most of the value.

There is also a genuine tension with morale: engineers want to fix what offends them, and always directing effort by interest rate means the unpleasant-but-harmless code stays. Some allowance for that is a reasonable use of the allocation, provided it is a small and acknowledged part of it.

Interview question

"Your backlog has fifty debt items. Pick the three you would do first and tell me what evidence you used — and then tell me which item everyone wants to fix that you would refuse."