Get certified - Transform your world of work today

Mapping and Costing Technical Debt

07/31/2014 by Glenn Bowering

Technical debt is a great analogy, because it takes a fairly complicated technical topic and creates an abstract analogy that is easily understood by anyone who's ever borrowed money. It's also a fairly robust analogy in that you can pull it and stretch it in different directions and it still makes sense. I would argue that the analogy is strong enough that you can pull it away from its abstract roots and back into the domain of concrete data.

Most people know they have technical debt in their code bases, but if you ask them how much, they struggle to quantify it. If you ask many developers where the technical debt exists, they'll point to the part of the code base they dislike working with the most; but if you ask them what the financial impact is, while they may wax lyrical about the evils of technical debt and how it slows development, they don't have a quantifiable answer.

This exposes one of the difficulties with technical debt. While business can appreciate the analogy, it falls short when asking questions such as, "Where is the technical debt, how much do we owe, how much is it costing us in interest repayments, and how long will it take to repay?" These are all questions business folk are used to having ready answers for when discussing financial debt, but when most technical managers are faced with these questions they are likely to respond with blank faces.

A corollary of this is that when developers want to repay the technical debt incurred, it's very difficult to justify spending the time and money. They are left struggling to find a fresh way of explaining the well-worn stories of the technical debt analogy. The justification for the debt repayment has to compete with new features to the software, which have (usually) undergone some cost-benefit analysis and will have answers to questions about return on investment or anticipated increase in revenue or traffic or some other easily quantifiable and understandable metric that business cares about. The reason is that the new feature requests often come from sales, marketing, or some other business-savvy part of the organization. Software professionals need to learn how to play the game.

This article presents two strategies for mapping your technical debt, the first of which can then be used to put a financial figure on the level of debt and your interest repayments. Both strategies require a fairly fine-grained, component-level architectural diagram. Component is an overloaded term in software, so choose whatever definition you're most comfortable with and which makes sense in your code base. Surprisingly, some organizations don't have this, but it's a fairly fundamental step toward managing your technical debt, so I would highly recommend creating one if you don't already have it.

The fine-tooth comb approach

This approach can yield a detailed map of your technical debt but requires a large, up-front investment of time and energy.

For each component or cluster of functionally related components:
  • Get together with a team of developers to estimate how long it would currently take to make a typical alteration/addition. E.g., if you have a component that is responsible for generating PDF letters to a customer, a typical change might be adding the ability to generate a new type of letter.
  • Ask the developers to discuss how they would ideally like to rewrite the component. The rewrite may encompass a few components with dependencies on each other.
  • Ask them to estimate how long the rewrite or refactoring would take. This constitutes the technical debt repayment, so the financial cost is the typical day rate of your developers multiplied by the number of days.
  • Then ask the developers to estimate the same typical tasks with the new (imaginary) component.
  • The difference between the two equals your interest repayments each time the component is altered.
It's interesting to note that the technical debt analogy differs from the its financial analog in that you only incur interest repayments when you make a change. Wouldn't it be nice if you only paid interest on your car loan when you used the car! You may want to think of a couple of change/alteration scenarios and figure out the different interest repayments for each. We will use this information later.


  • A fairly comprehensive mapping of where the debt lies.
  • If the developers' estimates are even remotely accurate, then you have a good understanding of interest repayments and the cost of repaying the principle.


  • The estimation and imaginary refactoring are potentially time-consuming.
  • The more developers involved in the estimation process, the better the estimates -- but this makes it more expensive.

Pin the Tail on the Donkey

You can think of this approach as a crowdsourced method of mapping technical debt. It will probably take longer in elapsed time but fewer actual man-hours to produce, and it's really simple to implement.
  • Take your architectural diagram and stick it to a corkboard.
  • For each bug found, you stick a pin in the component.
  • Over time, a pattern should emerge, showing where you have components that are defect hotspots.
Strictly speaking, a component with a high number of bugs doesn't necessarily have high technical debt, but it's fairly likely that there is a correlation. If you find one component collects too many pins, you can color-code the pins such that a blue pin means one bug but a red pin counts for ten, for example.


  • Very cheap to do. The only extra work involved is sticking a pin into your architecture diagram.
  • It's based on empirical evidence rather than on developer estimation.
  • It can provide you with a good idea of where you need to start repaying the debt first.


  • It's likely to take a long time to build up a picture of your defect hot spots.
  • It doesn't provide any indication of your interest payments.
It would be great if there were some plug-ins for defect mapping systems that did this for you automatically. You could even map the build-up (and repayment) of debt over time. While this approach doesn't provide you with any financial data, it's a cheap way of figuring out which parts of your system need to be addressed first. You can then apply the first technique to the parts that need it most.

Justifying technical debt repayment

If you've taken the first approach to mapping your technical debt, then you're in pretty good shape to make a justification for debt repayment. For each story or feature, decompose it into the changes or additions that you'll need to make to each component in your system. If your stories represent vertical slices through your system (as we would hope they do), then it's analogous to drawing a line through your architecture diagram and seeing which components you're going to "hit." For each component, look at the type of change you're going to make and sum up the interest payment you calculated for the change types. You can now say that for all the stories you've committed to in your next sprint, they are going to cost an extra £2,000 in interest payments (for example).

The most likely response to this new information is, "How much will it cost to repay this debt?" You can then look at the costs you estimated for refactoring or rewriting the components on which you're currently paying interest and provide an answer. The potential downside here is that the cost of refactoring all the components is likely to be an order of magnitude higher than the interest repayment, which may suggest to business that the interest repayment is acceptable. It's worth making the point that you can repay the debt in installments over a period of time and thus gradually reduce the interest repayments, as you would with financial debt.

It may be the case that business makes the judgment that the interest repayments are justifiable and chooses not to repay the debt. While this may be frustrating, it is ultimately a business decision, but at least it's now an informed decision.

Once you can quantify technical debt in this way, it leads to a number of other questions. For example, who's responsible for the technical debt? Even a moderate-sized business will have a financial controller. Who fulfills that function with respect to technical debt? Is anyone controlling the future acquisition of technical debt? Do we have a framework for deciding when it's appropriate to take on new technical debt? Do we have a technical debt strategy? How long till we reach a tipping point with technical debt and the only viable financial option is to start from scratch?

Food for thought, perhaps?