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 and why we should do it.

Any information system will probably at some point suffer from large scale or “macro” technical debt. This often happens when a project is implemented in a way that saves money in the short term but leaves technical debt that must be cleaned up at some point.

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.

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. (The cash flows are also discounted from the future to the present, but this is not relevant here).

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?