Pricing of technical debt
I talked recently about technical debt and the importance of cleaning it up via regular refactoring. This article will explain the pricing of technical debt in an agile software context and why we should do it. Technical debt is crucial to manage or it can end up killing your products and demoralizing your teams. Most teams and organizations don’t really understand or price technical debt. And this can lead to bad long-term decisions.
A quick summary of how and why we should price technical debt:
- technical debt decisions can have major long-term economic impacts
- these impacts are almost never understood or costed
- organizations therefore make decisions without understanding their economic impact
- by pricing technical debt decisions, we can better understand options and trade-offs
- NPV (Net Present Value) is the best way to price the long-term impact of decisions.
What is technical debt and why it is important
Any information system will probably at some point suffer from large scale or “macro” technical debt. I’m not here talking about small technical debt accruals. Things like a function having a bit more responsibility than it should, or validation code being duplicated across a couple of places.
I’m talking about the bigger, nastier type of technical debt. Debt that could take months or years to pay off. This often happens when a project is implemented in a way that saves money in the short term but leaves a big mess that must be cleaned up at some point.
Projects often fail to properly price technical debt
For example, it is built on a legacy stack instead of a new target-state stack, it duplicates data, it isn’t implemented with sufficient resilience or performance tuning, etc.
Convincing stakeholders to implement the project in a way that doesn’t create the technical debt can be a difficult conversation.
“But this way is cheaper!” is how the conversations usually end up. Then IT people draw diagrams illustrating that the solution is a poor one technically, they get overridden by business. Then the “macro” tech debt ends up getting created.
I don’t think it has to be that way, though. If the price of cleaning up technical debt is costed into the financials of the project, the result could turn out very differently.
How to price technical debt
There isn’t anything wrong with making decisions based on cost. The problem is, the decisions are often made without a good understanding of costs.
Firms usually only look at once side: the cost of doing it the “proper” way. They don’t look at the more hidden costs, of taking shortcuts and having to pay to clean it up later.
The quick summary of how to price technical debt is:
- technical debt decisions must be given a clear economic price or cost
- that decision and cost should be over time
- the costs over time should be converted to a current time cost via the Net Present Value financial method.
Examples of Net Present Value
The table below shows an example of project financials, based on the “NPV” model. NPV stands for Net Present Value, and is a common type of financial analysis. It is done by taking the initial project cost (capital expenditure or capex), and subtracting it from the net profit year-on-year for the project. This results in the net value of the project to the company.
Net Present Value can help make economic decisions for a project or product
The key point is that the money is discounted from the future (at an appropriate discount rate – don’t worry about what that rate is for now).
In the example below, the project initially costs $120,000 and provides net positive cash flows of $60,000 to the firm year on year for three years. The Net Present Value is therefore $60,000 (capex subtracted from net cash flows).
| Tech debt option | ||||
| Year 0 | Year 1 | Year 2 | Year 3 | |
| Initial capex | -120,000 | |||
| Ongoing benefits | 70,000 | 70,000 | 70,000 | |
| Ongoing opex | -10,000 | -10,000 | -10,000 | |
| Net profit (cash flow) | -120,000 | 60,000 | 60,000 | 60,000 |
| NPV: -120,000 + 60,000 + 60,000 + 60,000 | ||||
| = $60,000 |
The table below shows a projection with no shortcuts taken and no tech debt left behind. The initial capex of the project is higher ($140K instead of $120K), and therefore it has a lower NPV:
| No tech debt option | ||||
| Year 0 | Year 1 | Year 2 | Year 3 | |
| Initial capex | -140,000 | |||
| Ongoing benefits | 70,000 | 70,000 | 70,000 | |
| Ongoing opex | -10,000 | -10,000 | -10,000 | |
| Net profit (cash flow) | -120,000 | 60,000 | 60,000 | 60,000 |
| NPV: -140,000 + 60,000 + 60,000 + 60,000 | ||||
| = $40,000 |
On paper, it seems that the tech debt option would get chosen by any company. However, that is because the tech debt has not been priced or costed. Let’s assume that by the end of year 2, the technical debt will be mounting to the point where it must be fixed. It will cost $30,000 to do so. If you include that additional later CapEx into the model, it becomes a worse option:
| Properly costed tech debt option | ||||
| Year 0 | Year 1 | Year 2 | Year 3 | |
| Initial capex | -120,000 | |||
| Later capex to clean up tech debt | -30,000 | |||
| Ongoing benefits | 70,000 | 70,000 | 70,000 | |
| Ongoing opex | -10,000 | -10,000 | -10,000 | |
| Net profit (cash flow) | -120,000 | 60,000 | 60,000 | 60,000 |
| NPV: -120,000 + 60,000 + 60,000 + 60,000 – 30,000 | ||||
| = $30,000 |
Conclusions
The no tech debt option has a higher NPV ($40K versus $30K) and is therefore not only the “technically” better option, but financially too. You might find it much easier to have these conversations with the business if you can describe the problem in terms they are familiar with.
Question: have you ever had a difficult conversation about technical debt? And struggled to justify why a “better” technical solution should be chosen?
This video does a good job of summarising what technical debt is and how to manage it:
Frequently Asked Questions
How is technical debt cost measured?
The best way is to get dollar cost estimates for the work, and dollar cost estimates for the impact of the tech debt decision. And then use the Net Present Value method to discount those costs back to present value costs. I describe this method above.
Net Present Value is useful because it lets you turn future costs into a current dollar cost. It is a commonly used method in project finance.
What is technical debt and cost?
Technical Debt is when agile software teams make sub-optimal decisions or shortcuts, that will have a future impact on their performance, customer sastisfaction, product quality or reliability, etc. All technical debt decisions have a cost and risk.
What is the opportunity cost of technical debt?
Technical debt can have an opportunity cost if the decision prevents a team from working on other things. The value of those other things they could be working on (instead of paying down the technical debt) is the opportunity cost of the decision.
Should you estimate technical debt?
Yes definitely, at least for bigger items. If it is a small thing that can be fixed in a day or so, then there probably isn’t much point. For bigger decisions that a team could spend weeks or months on fixing, then estimating it is a good idea.
Because it lets firms make real economic project decisions about which path to take. Most firms don’t do this and just accrue the debt. That is because they are only pricing the development work, not pricing the impact of the technical debt itself.