Top Technology  /  Architecture & core decisions

Technical debt

Technical debt: how to measure what it's costing you

The concept

What technical debt is, without the jargon

Every time a team says "let's do this quick now and fix it later", your company takes on debt. It shows up on no statement, yet it's paid every month.

It's the future cost of software decisions made the fast way instead of the right way. Sometimes it's sensible —beating your competition to market can be worth a little debt—. The problem isn't having it: it's having it without knowing and never paying it down.

The cost of technical debt grows over time while it goes unpaid Real cost (grows on its own) What you "see" day to day time without paying down the debt →
Like credit-card interest: what you don't pay off doesn't sit still —it compounds.
The analogy

It's like a credit card. Financing an urgent purchase can be smart. But if you only pay the minimum month after month, the interest ends up costing more than the original purchase. Software works the same way: debt that's never paid down grows on its own.

Impact on the business

Why it should matter to you, who leads

Because technical debt doesn't stay in the IT department: it turns into business results you do see.

Every new feature takes longer

What used to take a week now takes three, because each change risks breaking something else.

Errors multiply

And with them, customer complaints, support hours and team burnout.

Risk piles up quietly

Fragile systems are also insecure systems. The bill arrives all at once, at the worst moment.

Your best people leave

No talented engineer wants to spend the day firefighting code nobody understands.

15–20%
of development capacity a healthy business devotes to keeping debt in check.
>30%
of time spent "firefighting" is the sign that debt already governs your operation.
up to 100×
more expensive to fix a defect in production than to resolve it in design.

Industry reference ranges for software. Real results vary by organization.

Measurement

How to measure what you can't see

You don't need to read code to size up your technical debt. You need to ask —and get answers in numbers, not excuses— these questions:

01

Delivery is slowing down

Compare how long deliveries took a year ago versus today. If the team is the same or larger but ships less, that gap is the interest you pay.

02

Firefighting ratio

What share of time goes to fixing errors instead of building? Above 30% sustained, debt already governs your operation.

03

The "bus factor"

How many people would have to be out for no one to be able to touch a system? If the answer is "one", you don't have software: you have a hostage.

Rule of thumb

A healthy business devotes around 15–20% of its development capacity to paying down debt continuously —refactoring, testing, documenting—. It's not an expense: it's the maintenance that avoids tomorrow's very costly rescue.

Quick diagnosis

Warning signs you can spot today

  • "Better not touch that, we don't know what breaks" is a common phrase on your team.
  • Every deployment is a stressful event, not a routine.
  • There's no test environment: your customers discover the errors.
  • Only one person understands how the most important piece works.
  • Estimates blow up and nobody can quite explain why.

Conclusion

What to do about it

Technical debt can't be wiped out overnight, and trying to pay it all at once is usually as bad a deal as ignoring it. The right answer is to make it visible, put a number on it and manage it: decide with data how much to pay down, when, and how much you can tolerate without risk. That's a business decision, not a technicality —which is why it belongs on your desk.

Do you suspect your software is costing you more than it should?

In a free assessment session we review your situation and tell you, in business terms, where your debt is and what I would do about it.

Book your free assessment
Back to Top Technology