Technical debt ratio

Technical Debt [TD] concluded that “Technical debt is the amount of work needed to decrease the total cost of a product“, which establishes a qualitative link between effort spent now and effort spent later. That link can be expressed quantitatively across projects of different sizes as the Technical Debt Ratio (TDR).

The Technical Debt Ratio is the amount by which an improvement changes a project’s total cost of ownership divided by the cost of that improvement.

TDR = Δ_TCO / _{improvement_effort}

Technical debt is imprecise

The issue with the previous TD definition is that debt is a quantity measured in money (equals effort equals time) while the same definition relates two costs: the total cost of ownership [TCO] vs. the cost of an improvement task. The aim is to make TD comparable across projects and organisations so that it can be used as a quality gauge for assessing the situation of a project and the delivery capability of an organisation. The original definition talked about “… the amount of work…”, aka effort aka cost, which is a number with a unit. Obviously, large projects tend to amass large TDs (in money-terms) and small projects smaller TDs, so technical debt can’t be used to compare dissimilar projects – yet. However it seems plausible that the ratio of TCO reduction to effort spent on the reduction should be similar for large projects (you spend a lot to gain a lot) and small projects (you spend little to gain little), so there must be a way of establishing a comparison.

TD and TCO

Let’s start with the accumulated cost of a project, thus the money spent on a project until a given moment in time. Obviously it’s an increasing function of time and its graph looks like this:

The project TCO is the integral of the cost over the lifetime of the project. We know the TCO only at the end of the project, although in a way it always existed. We can try to predict the TCO, but in the end it is and always has been and will be one number. Thus the TCO can be graphed at any point in the lifetime of a project as a constant number:

Imagine we put some effort into improving the project. At first look, this would increase running costs as the cost of the improvement effort is added on top to the already accrued cost, but it would reduce future spending (similarly to paying off a financial debt earlier). Below is an example of the project cost over time with (red) and without (blue) effort spent on improvement:

Project cost over time with and without improvement effort.

In the example above the improvement effort is spent early in the project as can be seen from the deviating project costs. The project without improvements (blue) is cheap in the early project phases but becomes more expensive in later phases, while the project with improvements is more expensive in the early phases, but the cost does not increase as much in later phases as it would without the improvements. The point at which the improvements are made is also crucial: generally speaking, early improvements benefit the TCO more than late improvements, but that is not a universal law. Eg. premature optimisation [PO] happens when improvements are made before it is clear that they are actually needed. Also, later improvements benefit from hindsight and experience collected during the project and can be more targeted and effective than speculative, early improvements.

It should be obvious then that the accumulated cost graph will vary on the amount and timing of improvements made. For simplicity I’ll assume for the remainder of this post that a single improvement is made across all projects compared at the same point in the projects’ life cycle.

Now let’s examine how the project TCO changes when we apply a single improvement at always the same time, but we vary the effort put into it:

The TCO initially drops as the improvement effort increases, which is to be expected since the project quality improves. But then the TCO increases again because the effort put into further improvements doesn’t lead to large quality improvements any more, but nevertheless increases TCO by the amount spent on the improvement, which is known as the point of diminishing returns [PODR].

Technical debt ratio

In the last example we examined how TCO changes with improvements. We can measure the amount by which TCO changes and divide it by the amount of improvement effort which defined the technical debt ratio:

TDR = Δ_TCO / _{improvement_effort}

Building on the contrived example from earlier, the TDR is positive as long as the TCO decreases, which means that until that moment improvements are meaningful. TDR peaks at some point where the the best value for the project is reached, although further improvements can still reduce the TCO. TDR becomes negative once further improvements cost more than they generate in savings, which is the point of diminishing returns where TCO increases and no further meaningful improvements can be made.

One probably wouldn’t want to invest past the point of diminishing returns into improving a project, so let’s focus on the first part of the graph. In reality, TDR looks more like a bell curve (though it doesn’t asymptotically go to 0 because overspending can easily return negative value), since low spending on improvements will usually not go past analysis and preparation without effecting any TCO reduction while over-spending on improvements increases TCO as we have seen.

Comparing TD ratios across projects

Looking at the TDR curve, three things stand out: the height of the curve, the width, and the centre.

The curve height shows the improvement potential for a project. Assuming large projects can be improved a lot, but also require large improvement effort while small projects can be improved only a little, but also require only little improvement effort, the TDR curve can be normalised by normalising improvement effort to the range of 0 to 1 which also normalises the curve height, making curves comparable between projects.

The curve width shows the cost of improvement, where a large width shows that a project can be improved continuously, while a narrow width shows that a project has limited opportunities for improvement – which may be a good thing, because it shows where improvement efforts should be concentrating on.

The curve centre combines improvement potential with improvement cost and shows where the best value for improvement lies. Ideally the curve maximises early, meaning that the TCO can be optimised by few improvements. A curve with a centre far to the right means that a project can only improved with considerable investment.