Nobody checks the interest rate on technical debt

Technical debt is the rare engineering metaphor that survived contact with management, and it deserved to: taking shortcuts to ship sooner really is borrowing against the future. But somewhere along the way the metaphor lost its most useful part. In finance, nobody discusses debt without discussing the rate. In software, almost everybody does.

Because here is the thing the metaphor knows that the discourse forgot: debt is not bad. Debt is a tool. Companies borrow deliberately to move faster than their capital allows, and the discipline is not avoiding loans, it is knowing the rate on each one and refusing the usurious ones. Software shortcuts deserve exactly this analysis, and almost never get it. Teams either moralize all debt as failure, which leads to gold-plating and missed markets, or normalize all debt as pragmatism, which leads to codebases nobody can change. Both errors come from treating debt as one undifferentiated pile.

It is not a pile. It is a portfolio, and the rates vary enormously.

Some debt charges almost nothing. The hardcoded config that one file reads. The missing abstraction in a module two people touch yearly. The clunky admin screen used only by your own team. These loans sit quietly, costing minutes per year. Paying them down eagerly is not hygiene; it is burning sprint capacity to feel tidy, and the market does not pay for tidy.

Some debt compounds daily. The schema shaped around a business model you abandoned, which now taxes every new feature with translation code. The absence of tests around the payment flow, which converts every deploy into a small act of courage and every refactor into a risk nobody volunteers for. The copy-pasted logic in six places that must stay accidentally synchronized. These loans charge interest on every single change the team makes, and their rate rises as the team grows, because more people pay the toll more often.

The skill, then, is not "reduce technical debt." The skill is knowing the rate, and the rate has a definition that fits in one sentence: how much friction does this shortcut add to the changes we actually make, times how often we make them? Change frequency is the term everyone drops. Ugly code on a path nobody modifies is a low-rate loan regardless of how offensive it looks in review. Mildly awkward code on the path every feature crosses is the expensive loan, precisely because it looks too minor to schedule.

This definition turns refactoring debates from aesthetics into arithmetic. Where has velocity actually degraded? Which parts of the codebase do engineers detour around? What does the bug tracker say about hot spots? That evidence identifies the high-rate loans, and those get paid down as part of feature work in that area, continuously, the way sane companies service debt. The low-rate loans stay on the books without guilt. Guilt is not a line item.

And one habit prevents most of the expensive borrowing in the first place: when taking a shortcut, write down what was borrowed and where it will pinch. A sentence in the pull request is enough. Loans are cheap to track at origination and expensive to rediscover during an incident, which, without the note, is when the rate finally gets checked. By the collections department.