“The system is getting sluggish.”
“We’ve got unusable features.”
“Our release cycle is too slow.”
If any of these sound familiar, it’s likely that you’re in debt. Technical debt, that is. It’s something your tech team will be acutely aware of, but what does it mean for your business and how should you address it?
Technical debt isn’t so different to financial debt; it’s something you’ve needed or developed that wasn’t in your plan or budget and it will cost you at a later date. And much like financial debt, the longer you take to pay it down, the higher the cost to your business.
Typically, technical debt arises due to the new release of a dependent system, or a short-term hack to satisfy an urgent business requirement.
It might be the result of a quick-fix development requested by an important customer. Perhaps you needed a new feature or a faster way to meet a business need. Or maybe your technical debt has occurred naturally, due to the new release of a dependent system. Because every time code changes or a new version is released, you incur a bit more technical debt. And much like missing a few small loan repayments, every time you skip a release, the version updates start to add up and your debt can build rapidly. Like all debt, it causes pain later down the line.
You may only realise it’s a problem when you decide to redevelop systems or your development team start to complain that they can’t develop new stuff because of technical debt. And then the debt becomes a barrier to future development. Because whatever the reason behind your technical debt, at some point you will have to pay it back.
Like any short-term workaround, you’re solving the surface problem by covering over the holes. But eventually, there are so many patches you can’t see the system properly. And the patches become a burden to your developers. Especially when something breaks.
The good news is, you’re not alone. Every SaaS has some sort of technical debt because it creeps in even when you’re standing still.
Let’s look at intentional debt first; a work-around that solves a problem right now but will knowingly create a longer-term problem or more complex development at a later date.
Imagine you are developing a POC and working on authentication for the app.
You know your clients all use Microsoft so you develop the app based on Microsoft authentication. It works and you get the POC out of the door.
Later, your clients decide they want to enable additional account-creation options. But the authentication code is so tightly bound to the Azure active directory that you’ll have to go back and rethink what you did and rewrite everything.
In this example, there is a balance to be had. You want to get an MVP up and running but you need to keep in mind the ultimate goal to avoid headaches in the long run. If you know that eventually, you might need to enable authentication from multiple sources, you can make sure the code is written in a more flexible way to allow for future development.
For intentional technical debt like this, there’s always a trade-off between the time it will take and the flexibility you build in. In this example, it would take less time to write code that is tied to a single authentication method. So the decision to take slightly longer to develop the MVP will save time and cost later on.
And like anything, it’s about striking a balance and accepting that you are knowingly building in technical debt that will have to be paid back at a later date.
Naturally occurring technical debt is a slightly different beast. 3rd party systems, directories, and libraries are constantly getting replaced due to new, improved versions or because vulnerabilities get discovered. If you remain on the same version and skip releases and updates, eventually that version will be out of support from the vendor. When a system is out of support, the risk to your business is greater because if (when) something breaks, it will take a significant amount of development time to resolve. So it’s a good idea to constantly ‘pay down’ that debt by keeping versions under control.
Top tip | Assign time in each development cycle to update all dependencies and underlying systems. Make a decision to change every time there's an individual release or, make sure you are within the ‘range’ for long-term support.
It does and it doesn’t. There’s nothing explicit within the Scrum framework to deal with technical debt.
But the natural2-week cycle of a Scrum means you have a regular opportunity to review your technical debt. So assign time at the beginning of every sprint cycle to consider any debt and deal with any security vulnerabilities as a minimum before you move on to anything else.
In order to define how much technical debt is acceptable, you’d need to first be able to measure it.
And whilst you can measure how many versions behind a release you are, technical debt due to quick-fix hacks or authentication developments are almost impossible to quantify.
You see, technical debt is insidious; it grows with time but the impact can creep up on you. High-performing software teams combined with low technical debt are able to release developments quickly with very few issues so although it’s almost impossible to measure tech debt and define how much is acceptable, here are some of the ways it might show up:
X A decelerating release cycle
X Time taken to get new releases into production
X A difficulty in getting changes through
X High number of issues or bugs in a new release
X Quick-fixes that haven’t got proper unit test running against them
X Software versions that are out of support (and out of official tolerances)
Top Tip: Consider taking Google Cloud's DevOps Quick Check (DORA: DevOps Research and Assessment) to measure your teams performance and compare it to the rest of the industry or see our Synetec DevOps services.
It’s impossible to avoid technical debt simply because of the nature of how fast things move. It creeps in even when you are standing still.
So it’s simply a question of making choices and managing it in a way that is acceptable to your business.
The simple answer is to assign a budget to pay it down. We’d recommend allocating somewhere between 10 and 20% of developer time each month to resolving technical debt issues. For a brand-new project, this figure could be much lower.
If your current system is in a good state in terms of structure and coding versions, it’s always worth fixing technical debt. However, if you have much older versions of a language or a non-supported coding language, you might want to consider migrating to a more modern platform.
You might also want to consider how many other systems are affected. The irony is that the bigger a tech debt problem gets, the riskier it becomes. But the bigger it gets, the less wiling companies are to deal with the debt; because the risk of breaking something else in the process is also very high.
Our advice? Always budget software development time to keep on top of technical debt. Deal with it in incrementally so it doesn’t build up and swallow your system (and your business with it!)
If you’re worried about your tech debt, we can help you get back in the black
If you would like to discuss a bespoke software development project, challenge or goal please book a 30 minute Clarity Call with us and we'll point you in the right direction (even if you chose not to work with us)
.png)
.png)
