Understanding Technical Debt to Inform your Operating Model
Understanding Technical Debt to Inform your Operating Model
Author: John Hewison, Director Liqueo.
What are we looking to do?
When designing your future state Target Operating Model (TOM), it is useful to understand how much Technical Debt you are carrying as an organisation. You should also look at where it sits and your options as to how (and if) you are intending to pay it back.
The purpose of the article is to shine a light on what is considered Technical Debt and how it can be viewed as both good and bad. But, of course, the first question is - what is Technical Debt?
When describing Technical Debt, it’s often easier to grasp the concept by comparing it to how we understand Financial Debt. The two are fairly analogous in that you are borrowing something now at the expense of paying for it in the longer term.
With Financial Debt, you may be looking to make a significant purchase today. You can’t afford to pay for it outright, so you need to borrow that money from a bank or similar lender. The expectation is that you will have to pay interest and then repay the capital you borrowed over the longer term.
With Technical Debt, we are potentially coding short or long-term solutions as a means to solving a problem. For example, we might have an urgent need to build an interface to feed ESG scores into our compliance trading system to meet a new regulatory requirement. There are a number of ways the developer can achieve this - and the time and effort spent to build the interface can be considered the Technical Debt the company is accruing.
Why is this considered debt? In short, because if the software is subsequently upgraded or the interface needs an enhancement, this will require time and effort to add the code change. If the code is clean, well-structured and reflects our current understanding of the problem then the change can hopefully be affected quickly and at low cost. Ward Cunningham, who coined the phrase ‘Technical Debt,’ views the time taken for developers to understand the code base and update it to contain our most recent understanding, as the interest you are paying on your Technical Debt.
Understand the concept.
Financial Debt can be viewed as both good and bad.
As a rational individual, you will usually look to borrow as much as you can afford to pay back in the longer term. That is, unless you have an emergency where you may need to borrow more than you are comfortable with. Usually, the aim would be that this debt would only be short term.
When does this become a problem?
Well, put simply, when you can’t afford to pay it back.
Applying this framework to Technical Debt, this happens when you have so much customisation, that without properly refactoring the code base, it becomes a cost inhibitor to move forward with any change.
In Ward Cuningham’s view, if you are rushing software out of the door but not applying your future learnings to the codebase, this is the same as continuing to borrow money without thinking you ever need to pay it back. At some point in the future, when you eventually have to change the code, you effectively spend so much time that it becomes cost-ineffective to make the change.
The ability to pay back the debt.
Others, like Martin Fowler, have looked at the idea that every time you add to your codebase it becomes “prone to the build-up of cruft”, Martin Fowler 2019 (to learn more about “Cruft”, see linked article). The less quality time you allow for enhancing the code, the more “cruft” you collect. His argument is that by devoting quality time to update the code when you add an enhancement, you reduce the level of cruft. In technical debit terms, you are reducing the size of your interest payments and thus paying the debt back quicker.
Martin Fowler also introduced the idea of the Technical Debt Quadrant to highlight four different types of Code Debt you may have taken on.
Why is this useful?
By categorising Code Debt, we can rationalise and explain it to others. We can show how decisions have or have not been taken regarding the design of that code and therefore the Technical Debt issues the company may face. This is particularly helpful when explaining these concepts to non-technical people. All this information should subsequently feed into any TOM to highlight areas of risk.
Reckless and Deliberate Debt.
This is the result of a considered, intentional failure to develop code without care for the long-term implications. In this case, the interest payments will be high and unsustainable since there is no plan to manage the debt.
Fowler argues, “The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the codebase.” The point being that this is ‘Prudent Debt’ because the developers have made a cost/benefit decision to take on the debt and deploy the release sooner (instead of paying it off).
When developers don’t implement good design practices, they create a breeding ground for inadvertent Reckless Debt. They don’t know what they don’t know, which causes a multitude of problems.
Finally, there are the situations where you have delivered your clean and well-factored code but feel you could have done more. You subsequently realise you could have used a better design pattern or solved the problem in a more effective way. This is referred to by Fowler as ‘Prudent Inadvertent debt.’ It is both inevitable and to be expected since no one can predict the future.
So, what other types of Technical Debt can you have?
Aside from Code Debt, which we have discussed, Michiel Mulders suggests there are three additional types of Technical Debt.
Documentation – All conscientious developers start with good intentions to create supporting documentation for their code. The debt accrues when this is poorly maintained - causing misunderstanding between developers and leading to bugs or new code debt.
Security – This type of debt grows as you inherit or fail to spot software vulnerabilities through your development process. It presents a significant risk that should not be underestimated and is best reduced through repeated security testing and monitoring.
Tooling – This is caused by a failure to ensure every one of the developers uses and knows how to implement the relevant development tooling.
Why is it important to get a handle on it.
So, we’ve identified the numerous types of Technical Debt and understand that Technical Debt is effectively an inevitable consequence of development. As an organisation approaching a new TOM, it is wise to weigh up how much Technical Debt you are carrying, in what forms it occurs and in which parts of your organisation. This allows you to make an informed decision on whether to Build, Enhance or Buy - as you look to move forward.
Earlier, we gave the example of taking on Technical Debt when building an interface to load ESG scores. When making this example, we talked about the idea that we had created the debt when we built the interface. If, as part of the new TOM, we were looking at implementing a new trading system which already included an inbuilt ESG interface, then we can assume there is now no Technical Debt to carry forward. The counter to this is that we have not eliminated the Technical Debt. We have just shifted the responsibility to the 3rd Party provider or Outsourcer (which may or may not be the correct thing to do). There may be a number of reasons you wish to retain your Technical Debt. What is important is to ensure this is limited and Prudent.
To conclude, I will leave you to reflect on an interesting statistic I discovered whilst researching the article. A survey by Software AG 2022 of 700 IT decision makers around the globe, found that 25% of firms’ technology budgets, on average, is diverted to resolving Technical Debt issues. I will leave you to decide if you think this might be an issue.
For more information on how we can help with your Target Operating Model Transformation, please contact us.
