Technical debt never sends an invoice. It shows up as a release that slips by a week, a change everyone called simple taking three days, and a senior engineer spending Monday morning explaining why the system can’t just do the obvious thing. None of that gets a number attached to it, so it never competes for budget against the things that do.
What it actually is
The metaphor is Ward Cunningham’s: shipping code you know isn’t right is like borrowing money. Fine if you pay it back soon, expensive if you let the interest run. Some debt is deliberate and correct. You take the shortcut, you make the date, you fix it next sprint. Most debt isn’t decided at all. It accumulates as requirements change and the people who understood the original design move on to other things.
The existence of debt isn’t the problem. Healthy teams carry it on purpose. The problem is that it is almost never written down anywhere you can sort. It lives in the heads of the two people who know which module is fragile, and in comments that say // do not touch. Nothing you can’t list can be prioritized, and nothing you can’t prioritize ever gets budget.
Technical debt is a real and growing liability that sits entirely off the books. No owner, no line item, no register. Then one quarter it becomes the reason you can’t ship.
Why it gets worse rather than staying still
Debt would be manageable if it held its position. It doesn’t, for three reasons.
- It compounds. Each shortcut makes the next change harder, which makes another shortcut more tempting. Fragile code attracts more fragile code, and the rate picks up as the system grows.
- The people funding it can’t see it. Debt lives in the code; the roadmap gets set in a meeting room. By the time the cost surfaces as a vague complaint about velocity, it is months downstream of the decisions that caused it.
- It taxes everything downstream. Onboarding is slower, estimates are less reliable, incidents take longer to close. Good engineers burn out maintaining code they can’t safely change, and the best of them leave with the context in their heads.
The cost you won’t find on a spreadsheet
We are not going to quote you an industry percentage here. The published figures vary widely enough that you can find one to support whichever argument you already wanted to make, and none of them were measured on your codebase. What we can say from our own delivery work is where the cost tends to show up, and it is rarely the line item people expect.
Engineering hours are the visible part, and they are not the expensive part. The larger cost is in what didn’t happen. The feature that never got built because the team was busy routing around the module nobody wants to touch. The release that missed the window it was aimed at. The reorg after an outage in a service with no clear owner. Debt costs hours, but mostly it costs options, and options don’t show up in a retro.
“We’re not slow because the work is hard. We’re slow because we’re afraid to touch anything.”
Why it usually goes unmanaged
Most teams know perfectly well that they have debt. What they don’t have is a way to see it as one prioritized list across every repository, rather than a scatter of TODOs, linter warnings and Slack threads. Without that list, the same three things happen everywhere.
- Debt gets argued about anecdotally instead of triaged by impact, so the loudest engineer wins.
- The same issues are rediscovered every few months and re-litigated from scratch.
- When debt does get paid down, there is no record of what changed or why, so the audit trail goes with it.
How we handle it in ADIS
We treat debt as a stage of the lifecycle with its own place in the system rather than a chore competing for whatever time is left over. The aim is narrow: make it visible, make it rankable, and keep the history when it gets cleared.
Debt is detected and pulled into a single list spanning all connected repositories, so what used to be tribal knowledge becomes something you can query and sort.
Findings are grouped by type and severity so the debt that genuinely threatens delivery comes to the top, and the roadmap argument starts from evidence.
Resolved findings are batch-cleared while what was fixed stays on file. You burn debt down quickly without erasing the trail, and the same issues stop coming back.
Because ADIS knows which branch is running in which environment, you can see not just what is wrong but where it is live right now.
None of this makes debt go away, and any tool that claims otherwise is selling you something. What changes is that debt stops being a mood the team is in and starts being a list with owners and dates on it. That is roughly the difference between a team that is nervous about its own system and one that isn’t.