arrow_backAll articles

Technical debt management: how to measure, manage and pay it down without a big rewrite

· Josef Chmel

Technical debt management: how to measure, manage and pay it down without a big rewrite

Technical debt costs developers hours every week and costs the company part of its new-feature budget. What Stripe, McKinsey and Google found, and how to manage it as a normal line in the plan.

Every head of a software company knows the pattern: the team says "this has to be rewritten first", estimates for new features keep growing and simple changes take weeks. Behind it there is usually technical debt – shortcuts, outdated dependencies, missing tests and documentation that piled up while the company was shipping. Debt in itself is not a mistake. The mistake is when management doesn't know about it, can't put a number on it and lets it grow. Let's look at what the data says and how to handle technical debt management in practice.

What technical debt costs

In 2018 Stripe, together with Harris Poll, asked more than 1,000 developers and more than 1,000 C-level executives in five countries where their time goes. According to the survey, out of a 41.1-hour work week the average developer spends 13.5 hours on technical debt and another 3.8 hours fixing bad code. Respondents named maintenance of legacy systems and technical debt as the top drag on productivity.

McKinsey confirms it from the budget side. In a survey of 50 CIOs at financial-services and technology companies with revenues above $1 billion, they estimated that technical debt amounts to 20–40% of the value of their technology estate, and that 10–20% of the technology budget for new products is in fact diverted to resolving issues related to tech debt. 60% of them felt their debt had risen perceptibly over the past three years.

What technical debt costs: developers spend 13.5 of 41.1 hours a week on it, 10–20% of the new-product budget goes to resolving it and it makes up 20–40% of the value of the technology estate

For a smaller software company the absolute numbers differ, but the principle is the same: every hour spent working around an old solution is an hour you can't bill a client as new value – or you bill it and the client wonders why a small change cost so much.

Not all debt is bad

Martin Fowler proposed a simple quadrant that helps you talk about debt without blame. Debt can be deliberate or inadvertent and reckless or prudent:

  • deliberate and reckless – "no time for design": the team knowingly cuts corners, often because it underestimates how much a clean design would speed it up,
  • deliberate and prudent – the team knows it is borrowing (for example to hit a release date) and accounts for the cost of paying it back,
  • inadvertent and reckless – the team doesn't know good practices and builds up debt without realising it,
  • inadvertent and prudent – even an excellent team only learns during development how the design should have looked. Fowler calls this inevitable.

Martin Fowler's technical debt quadrant: deliberate or inadvertent and reckless or prudent debt

The key takeaway for a manager: prudent debt is a legitimate business decision, just like a loan. Fowler also points out that in code that is rarely touched, paying the debt down often isn't worth it – the "interest" is small. Paying down makes sense where the code changes often and the debt keeps slowing the team down.

How to measure technical debt

Google has been working on managing technical debt for several years; Ciera Jaspan and Collin Green summarised the results in IEEE Software. Their quarterly engineering survey tracks how often engineers run into each type of debt and how much it hinders them. The most frequently reported types include:

  1. migration needed or in progress,
  2. project and API documentation,
  3. testing,
  4. code quality,
  5. dead or abandoned code.

What didn't work is even more interesting. The researchers tried 117 metrics from engineering log data to see whether they could predict debt without asking people. They called the results disappointing: no single metric predicted where engineers report technical debt.

Google research: the five most frequently reported types of technical debt and 117 metrics, none of which alone predicted where developers report debt

What this means for a smaller company:

  • Ask your people. A short regular team poll ("what slowed you down most this month?") tells you more than a single score from a code analysis tool.
  • Split debt into categories. Google's list is a good start. Documentation debt looks very different from an unfinished migration.
  • Treat tools as a signal, not a verdict. Google uses tooling that flags issues such as poor test coverage, stale documentation or deprecated dependencies – but people decide the priorities.
  • Track time. If work on debt is logged against separate tasks, after a few sprints you know exactly what it costs you.

How to pay it down: five rules

McKinsey recommends treating technical debt as a business issue, not only an IT concern. Combining its recommendations with Google's experience gives a simple approach:

  1. No big rewrite. McKinsey explicitly warns against "big-bang" debt projects and recommends earmarking part of the capacity for steady paydown. A completely new stack only makes sense where the debt is so large that fixing it isn't worth it.
  2. Give the debt an owner. Every system should have a clear owner who decides what gets paid down, what is left alone and what gets replaced.
  3. Reserve capacity. McKinsey gives the example of agile teams where a "spare pair" of people in a ten-person team works on debt. According to McKinsey, actively managing debt can free engineers to spend up to 50% more time on work that supports business goals.
  4. Debt belongs in the backlog. Every known piece of debt should be a separate task with a description, impact and estimate – not a note in a senior's head or a TODO in the code.
  5. Manage it, don't try to erase it. The goal isn't zero debt but debt whose cost you know, paid down where it pays off.

How mcptask.online helps

In mcptask.online technical debt is recorded as regular work: its own Epic with Stories and Tasks, with a priority and scrum points that automatically turn into an hour estimate. Dependencies are real blocker links – when a new feature waits for a migration to finish, the blocked task drops out of the queue and comes back on its own once the blocker is done. Time is logged straight into tasks, including from commits, and a timesheet in JSON, CSV or PDF shows how many hours the debt really costs. Tasks from Jira, Trello or Redmine come over via import.

Small, well-described technical debt tasks – adding tests, updating documentation, removing dead code – are also ideal work for an autonomous AI developer (the runner). It takes tasks from the same queue as your people, writes code and tests, and the pull request is merged only after the tests pass. Meanwhile your developers can focus on the harder problems.

Want technical debt in your backlog rather than in your seniors' heads? Sign up for mcptask.online – the first 30 days are free, no credit card required.

Sources