What is technical debt?
Digital transformation can take on many shapes and sizes. Imagine you’re looking to streamline your digital processes and your IT team have identified some cost savings which could be achieved by changing existing code… You may find that this results in some technical debt. But what exactly is technical debt?
Technical debt is the cost of rectifying previous coding solutions that have been used to hasten the delivery of a project, commonly at the cost of functionality.
Like financial debt, technical debt allows you to get (deliver in this case) something before you’ve got the resources to pay for it in full. This metaphor doesn’t stop here, it’s got legs. Like financial debt, technical debt can be the victim of interest. As updates are pushed, as designs and functionality shift, the software can begin to decay if not maintained. This is known as software entropy, when code can lose continuity with the rest of the software, resulting in a misaligned digital landscape within an organisation. This can further compound technical debt making it more expensive to amend than if done so initially. In order to successfully manage and maintain a digital transformation change project then you need to know how to measure technical debt.
How do you measure technical debt?
There are many ways to measure technical debt, such as cycle time, code churn, and code ownership. These are all methods of measuring specific variables within the lifecycle of development. However, if you’re going through a digital transformation project then you’ll want to look at measuring technical debt as a whole, and will need to look at the technical debt ratio (TDR).
TDR is defined as the ratio between the cost to fix the codebase and the cost to build it.
Let’s run through an example:
Our codebase has 18,951 lines of code.
On average, it takes 0.22 hours to complete a line of code.
Multiplying the number of lines by the time to complete each line will give us the total cost of the codebase:
0.22 x 18,951 = 4169.22 hours
Remediation time is the time taken to pay off our technical debt. This is a little trickier to work out. We need to predict the time it will take to pay off our debt. This is done by going back through to fix the areas of the code where we sacrificed functionality in favour of delivery speed. Let’s say 1200 of our lines require remediation. So, the remediation time is calculated as follows:
0.22 x 1200 = 264 hours
That’s 264 hours to address the lines of code where we accrued our technical debt. We can now put these values into our TDR formula:
TDR = (cost to fix / cost to build) x 100%
(264 / 4619.22) x 100 = 5.7%
Our TDR in this example is 5.7%. That’s 5.7% of the total cost to build the software that will be further required to fix it.
Technical debt is, at some point or another, inevitable during digital transformation. However, it is not always negative. Leaning on our financial metaphor once again, like financial debt, technical debt can be used to increase growth if managed correctly, and so positively impact your digital transformation journey.
This begs the question:
How much technical debt is acceptable?
The example above suggests that the lower the TDR, the better. In fact, data shows that companies with lower levels of technical debt yield better digital adoption and have higher revenue growth. Well, that was quick, problem solved; keep the TDR as low as possible right?
Unfortunately, it’s not that simple. We’re now leaving the world of hard quantitative numbers and entering the land of context and qualitative data. Context is huge in identifying what is an acceptable level of technical debt. The type of technical debt is the first piece of context we need to consider. These can be categorised into four types, known as the technical debt quadrants.
Deliberate & Reckless debt is accrued when there is sufficient knowledge of how to develop a fully functioning codebase, but speed of delivery is prioritised over quality. You may have fast turn around of your digital transformation targets but continued digital adoption could be difficult to achieve.
Inadvertent & Reckless debt is accrued totally unintentionally; when the aim is to develop a fully functioning codebase, but the knowledge is not at capacity to do so.
Deliberate & Prudent debt is accrued when a decision is made to deliver the codebase earlier and tackle the functionality problems later.
Inadvertent & Prudent debt is accrued when a more effective solution for the codebase is only found once the code has been implemented. Digital transformation is all about proper planning, which falls down in this quadrant.
Understanding where your technical debt is coming from can help in identifying whether the technical debt is adding or decreasing value. The type of technical debt does not have an impact on the TDR itself, as the TDR outlines the resources required to fix the code base. However, understanding where the technical debt is coming from can inform you on what can be considered an acceptable level. With data collected around your technical debt you will be better informed to more effectively deliver future digital transformation projects.
Suppose we begin a digital project with the intention of having 10% technical debt. If we realise, after implementation, that there has been additional debt accrued within the inadvertent category, this could be deemed unacceptable. In contrast, if we realise that there is the possibility for undertaking additional debt before implementation, in a deliberate and prudent manner, we may be able to justify this due to the benefits it can bring, such as being able to present a foundational model to the customer earlier.
Overall, being conscious and intentional about the technical debt you are undertaking is the greatest factor in understanding the value being added by your technical debt.
Technical debt is somewhat inevitable when taking on digital transformation projects but having a clear understanding of what to expect could be an advantage. Our team of expert consultants have worked with a variety of clients on helping them to realise just that. If this sounds like something you want to know more about then why not give us a message?
