The 80/20 rule to deal with technical debt & refactoring

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. Don't forget to subscribe to my YouTube channel and follow me on Twitter to keep learning with me and grow your career in digital.

Until next time, stay safe and see you soon.