Let’s talk about technical debt. We know, we know - we can sense your excitement from here…
You might have come across the term ‘technical debt’ if you’ve been involved in software projects, or maybe it’s just a phrase you’ve heard thrown around by your development team. To the ill-informed, this can be enough to set off alarm bells in your head - after all, debt rarely has the best of connotations, right?
But fear not; technical debt isn’t so much about finances, meaning you won’t have the loan sharks knocking and you don’t need to be securing your next round of investment on Dragons’ Den. So the question is, what does technical debt mean, and what impact can it have on your software projects?
There’s plenty of general discussion about what technical debt is, and the phrase is commonly used across the industry as a catchall covering everything from legacy code and bugs to missing documentation. Some think of it as an industry buzzword, while other definitions have become highly nuanced, and as a result it can be a challenge to articulate this in a way that’s clear and concise to a range of audiences - especially those team members and stakeholders from less technical backgrounds.
With all this in mind, it’s important to note that the information we cover here is primarily an opinion - but here’s what we understand technical debt to be, and how we approach it as a company when working on our digital projects.
So, what is technical debt?
When breaking down what technical debt is, it’s key to keep in mind from the get-go that not all debt is equal. Think of it like financial debt. An overdraft might have high interest rates associated with it, whereas a mortgage may have a lower rate but equate to a higher value over time, for example.
For those from non-technical backgrounds, understanding this concept and its implications is half the battle. It often sounds negative, especially to those focused on project management and delivery, but any and every project is likely to have some level of debt - it happens, and that’s OK! Just like a mortgage, this debt isn’t necessarily bad when managed correctly, and knowing about it means that you can make informed decisions.
To put it another way: when adopted with the right know-how, technical debt is a deliberate and strategic tool.
As any developer will tell you, it’s often the case that the code involved in a software project is worked on to a painstaking level of detail and attention. It’s not uncommon to have a comprehensive set of automated tests that might not even hit your production environment, for example, while the ‘quick fix’ that was meant to be in production for a few days or weeks ends up being left for years.
In these instances, it’s not always the debt incurred in the project that needs to be taken into account, but rather the interest rate (or, to extend the metaphor further, the overhead) that can occur in the not-so-distant future.
What do we mean by this?
Alright, enough with the finance talk - we feel like we’ve used more jargon than Martin Lewis! Let’s ditch the analogies and take a look at how this concept applies to a technical example.
So you have your proof of concept (POC) or minimum viable product (MVP) - nice work. Due to the nature of these deliverables and the time constraints placed upon your development team in getting your product shipped to receive user feedback, it’s likely (although not always a certainty) that some technical debt has been incurred. If the entire purpose of your POC is to determine the viability of taking the idea mainstream, this is no problemo.
However, technical debt isn’t a corner-cutting cheat code - it has consequences that must be considered in your approach. For example, if this POC is then built on and starts taking a different shape, this can mean that the decisions made in the early stages of the development cycle can have a knock-on effect on the process later down the line. The result? Future feature development can end up taking longer and costing more.
It’s all about finding that balance by weighing up the short-term benefits against the longer-term implications. How much longer is it going to take? How much more will this cost later down the line? And most importantly, how often does this happen (ie. how frequent is development in the area where the debt has been incurred)?
Incurring technical debt for a project that needs to be built quickly, if only to obtain user feedback and determine viability, is not a bad thing. After all, the delivery team can create a list of areas to come back to later and prioritise making the decisions that are more in-line with the overarching objectives of the project at that time. This approach is efficient and effective.
But in situations where technical debt has more substantial implications, a strategic balance must be achieved. For example, if your answers to the aforementioned questions were something to the tune of ‘a lot’, it’s not uncommon for this to spark the conversation of ‘starting again’, or using the data generated in your POC to inform the development of later versions of your product.
A good way to evaluate the impact of technical debt is to think of it as high interest or low interest (oops, looks like we weren’t quite done with the financial analogy after all). In other words, how much more will you be paying back in the future?
- High-interest technical debt: this is often found in ageing software, and is typically incurred for a whole host of different reasons. But what’s the impact of it? Well, your team probably won’t want to work on it for starters, as it will likely take a significant amount of time for your team to work around years of legacy decisions that may no longer align with the current needs of the platform. And even when development has been completed, the likelihood of regressions or new bugs is still high. Of course, it’s best to avoid building up this high-interest technical debt, but in instances where it’s already been incurred, there is definitely value in taking the time to determine why those decisions were made. Don’t just accept it for what it is, as the high-interest technical debt presents a unique opportunity to obtain a greater understanding of the application as a whole
- Low-interest technical debt: low-interest technical debt isn’t necessarily easier to address - code could still be complicated to deal with, for example. However, tackling this type of technical debt is often over quicker, or in an ideal scenario, can even be avoided entirely. It will typically have much smaller-scale implications, both in the number of people it affects and the impact it has on the project as a whole. Think of it this way: if your high-interest technical debt is taking out a loan with a whole lot of APR, then your low-interest accumulation is borrowing some money from a friend who might not even ask for it back!
That’s not to say you’ll always have complete control over the amount or type of technical debt you incur. In fact, in some instances it’s all but unavoidable. For example, there is a technical debt incurred over time from any packages, framework, or language usage. To build software, you’re going to be using at least one of these (and in modern web development, likely all of them), and this means you’re guaranteed to begin building up technical debt from the off.
That’s because, to stay secure and get access to new features, these will all need to be upgraded regularly, sufficiently maintained, and given consistent close attention - and this all equates to a certain degree of technical debt.
How much? Well, while this may start as low interest and seemingly low priority, it can quickly become the biggest pain point for new development or even the maintenance, bug fixing, or security of the system. So, this kind of debt should be paid down regularly through consistent updates and maintenance on any software system to avoid it becoming high interest. You’d be surprised at just how quickly this can happen, too - because this debt is inherent when you take on building a software, it builds up even with no changes to the system. So ignore it at your own peril!
Using the debt figure to inform decisions
As we hope we’ve established by now, incurring technical debt can be strategic - and for this reason, it should play a major role in decision making.
Technical debt needs to be acknowledged by all stakeholders in a project and should form a key part of the context to your decision making. It’s absolutely vital that everyone understands the costs both in the short-term and long-term, so that a decision can be as informed as possible. This isn’t so that you can pin the blame on someone, but instead to ensure you have that all-important context as to why decisions were made when reflecting further down the line.
When making project decisions, as a rule of thumb, ‘good’ technical debt should be considered as those low-interest accumulations that are normally incurred to meet business deadlines. This might be some low-priority optimisations, for example, that would result in small improvements to the overall code quality and potentially spur minor performance improvements in sprints, and have minimal cost to the project unless being actively developed.
We consider ‘bad’ technical debt, on the other hand, to be built-up in instances where the delivery team will take much longer to develop new features, and upgrades send chills down the spines of all those involved (and if you think we’re being dramatic, just ask your tech teams!). The resulting impact is that revenue opportunities are often missed due to the lack of agility, and it’s often tough to build strong business cases due to the time and costs involved with implementing more substantial change.
This can quickly have a domino effect, too. Prolonged time and budget estimates due to high-interest technical debt will quickly become accepted as the norm, which significantly reduces the desire to improve and drive change because it simply becomes too much effort.
Don’t be fooled into thinking you can just start afresh, either. In fact, this almost always presents a whole host of new hurdles to overcome, which are often far tougher to clear than when tackling non-technical debt head on.
The benchmark for starting again due to technical debt needs to be high and is not a decision that should be taken lightly, which only highlights just how important it is to get your decisions right the first time around. Ensure your approach is considered and well-informed to give you a great strategic advantage when delivering on a project, but always ensure you make each decision with both awareness and caution.