Writing / 2016
The True Cost of Technical Debt, and How to Measure It
Tech debt gets ignored until you price it. Track cycle-time drift, incident attribution, and engineer-days lost, then pitch paydown as a business tradeoff.
Every engineering team I’ve worked with complains about technical debt. At a mobility startup, on client projects in my consulting years, at every company I’ve been part of. The conversations sound the same. “We need to refactor the billing module.” “The test suite is broken.” “Nobody understands how the queue system works anymore.”
And then nothing happens. Or worse, leadership approves a vague “cleanup sprint” that accomplishes nothing measurable, and next quarter the same complaints come back louder.
The debt isn’t the problem. The inability to quantify it is.
Ward Cunningham coined the metaphor in 1992, and he chose finance deliberately. Debt has a principal and an interest rate. You can calculate whether it’s worth carrying or paying down. But most engineering teams skip the math entirely. They treat tech debt like a feeling: something you gripe about in retros but never attach a number to.
I’ve been guilty of this. Early at the mobility startup, I’d walk into planning meetings and say things like “the data layer is fragile” or “deploys are getting riskier.” True statements. Completely useless for getting resources allocated. The product team heard “engineers want to rewrite things instead of shipping features.” Which, from their perspective, was a reasonable interpretation.
What changed was when I started tracking three things. First, how long the same type of task took six months ago versus now. Second, how many incidents traced back to the same modules. Third, how much engineer time went into those incidents, counting the fix, the investigation, the communication, and the customer support follow-up.
The numbers were ugly. A task category that averaged two days in mid-2015 was averaging five days by early 2016. Same complexity, same team size. The difference was the accumulated mess in three interconnected services . One module was responsible for four incidents in a single quarter, each burning two to three engineer-days when you counted everything.
Suddenly I wasn’t saying “the billing module is fragile.” I was saying “this module cost us roughly ten engineer-days last quarter in incidents alone, and it’s adding three days to every feature that touches payments.” That’s a number a CEO can reason about. That’s a number you can weigh against a feature roadmap.
The fix doesn’t need to be dramatic. One team I worked with allocated 15% of sprint capacity to debt work. Not negotiable, not borrowable. Small, targeted improvements. Tighten a function while you’re already in the file. Add the missing integration test before you move on. Replace the brittle dependency before it causes another 2am page.
Compound interest works both ways. Small consistent payments on debt keep the codebase healthy enough to move fast. Skip those payments and the interest compounds until a “small change” takes a week and every deploy is a coin flip.
The teams that handle debt well can tell you exactly what their debt costs. They measure cycle time trends. They track incident attribution. They know which modules are hotspots and what those hotspots cost per quarter in real engineer hours.
If you can’t put a number on your tech debt, you can’t make a rational decision about it. And if you can’t make a rational decision, you’ll either ignore it until it cripples you or waste time on cleanup that doesn’t matter.
Measure the pain. Do the math. Present the tradeoff in terms the business already understands. That’s the whole strategy. Everything else is just complaining.