Technical debt is one of the main reasons why developers will always have a job.
The challenge is that product owners don't have time to deal with it, because it's hard to prioritise this in the backlog over new shiny features. And clients usually don't want to pay for it as they don't see any immediate return.
But turning a blind eye is just kicking the can down the road. It's really time to invest in the future of your digital product and deal with technical debt. Let's get to it.
Technical debt is normal
So let me be clear: technical debt is part of every digital projects and tool. This is completely normal. You cannot blame your developers for failing to deal with it.
As time goes by and you keep adding more features to your product, new dependencies are being created. Most of the time, the root cause of bugs or issue is related to two different components being built at two different times and interfering with each other... in some ways that even the best human testers wouldn't have predicted.
As the understanding of the entire product increases, the developers realise that there are better ways to structure the code. There are also a lot of external factors such as new standards or best practices that are emerging...
Invest the time in refactoring
Investing in reducing your technical debt is often referred to as refactoring. It means that you have to rewrite small pieces of codes from the existing features. It does not add any visible benefits to the end-users in terms of new screens or your features, but it will do a lot of things.
- First of all, it will improve the readability of the code for the developers, making them more efficient over time.
- Second, it will improve the security for the product owner and the end users by always being on top of the potential vulnerabilities.
- Third, it will improve the stability of the application with more tests to reduce the risk of bugs appearing.
- Fourth, most of all, it is there to improve the efficiency of the developers. You want your development team to add new features. You need them to work with clean code and not waste time dealing with five-year-old outdated functions.
In a typical digital team and in a product sprint, I recommend applying the Pareto principle: by allocating up to 20% of the time, budget and effort to refactor the code, you will drive 80% of the benefits I just listed.
How to structure your team
In practice, if you have a small team of four or five developers, one person could be dedicated to this pretty much full-time. I understand that some developers or most developers prefer to work on new features and not necessarily having to deal with all code, but the best software developers actually understand the importance of this and they enjoy tackling this technical debt. So I recommend you rotate the team members on every sprint to avoid boredom.
If you work alone, you should dedicate, I don't know, one day per week to improve the underlying code, the tests and patch the framework.
Refactor before it's too late
Trust me, I have seen it with some of our corporate clients. Refactoring can be expensive as an isolated exercise, but it will be a lot cheaper in the long-term. It is much better to continually maintain it. Otherwise, it will become unmanageable... in three, four years' time, you'll have to rewrite everything from scratch! That will be much riskier and much more expensive.
I hope this opened up your mind to the importance of investing in refactoring. If you're struggling with technical debt or need some help with your products, just get in touch on Twitter @sylvainreiter
If you prefer the video version of this article, head over to https://youtu.be/ZwNa5IYULeM
Top comments (4)
I wish I could give you more than 1 like.
TD isn't just about writing clean code these days, it is also about keeping up with the ecosystem. We used to have a 2 year software update cycle before there was a new version of .Net or c#. Heck PHP and JS, the backbone of the web got almost no updates for nearly 10 years in the late 90s, early 2000s. Now there is an evergreen browser and desktop with new JS features every year and framework enhancements every 6 months providing missing functionality that eliminates The need for crappy workarounds. E.g. nullish coalescing in JS removes multiple levels of nested if object === undefined
Yes Aaron, I feel what you mean! The cycle is so much shorter that you cannot avoid waiting for several releases to "plan" updates. It's not easy to implement in practice, I am in an agency but I imagine it's the same client-side.
Great article, thank you! I’ve always tried to take the Boy Scouts approach of leave the code base a little better than you found it each time you visit legacy code. Sometimes that means a quick little refactor and sometimes that means a more in depth restructuring. It feels great to delete 20-50 lines of newly redundant or obsolete code while improving an apps structure and maintainability.
Thank you for bringing attention to that topic.