How do I approach technical debt?
In my job, people frequently ask me how I approach technical debt. So I decided to write about my process for tackling this very thorny question.
I hope this will be useful for some of you out there, who are looking for guidance.
Why a thorny question?
Technical debt is the accumulation of defects or imperfections in the process of engineering a product. Here, I am going to talk specifically about Software engineering.
It is often the result of decisions made when choosing between time, cost and scope. Thus, it impacts quality, as illustrated below, in the well-known Project Management Triangle.
It can be tricky to manage because of this simple truth: The more you have, the more costly it is to manage it. And the more problems you will have adding value to your product in the future.
Perfection is costly
You may try hard to make your engineering practices perfect, to find the right way to solve a problem, there will always be another way, a different technique, a new tool that does it better.
So, if you wish to make the perfect product, you will have to rethink, rewrite, refactor, replatform, constantly. This will inherently increase your engineering costs and slow you down in adding valuable features to your product.
If your business relies on the value brought by its products and the cost optimisation of their engineering, which it usually does, you will have to find the right balance between tackling technical debt and adding value.
My approach to technical debt
The balance
In every situation I have to choose between adding value and dealing with technical debt, I try to answer the two following questions:
- How much value will this new feature add to our product?
- How much more will it cost us down the line if we don’t take care of this debt now?
The idea is to make informed decisions depending on concrete data. It is complicated to measure those two things, but I don’t think we need to be perfectly accurate about it (perfection is costly, again).
Most of the time, this simple exercise will make the answer very clear. But if it doesn’t, there is the conversation.
The conversation
Managing technical debt is often a question that concerns both Product Management and the Engineering Team, at least.
When data is not enough, the conversation between those two parties will involve other factors. For example:
- What’s our strategy for the product?
- What does the market look like?
- How fast do we need to be?
- How much risk can we take?
- How does this align with our engineering values?
Bear in mind it is hard to make everyone happy. But a good conversation involving maximum collaboration and trust has the benefit to bring everyone together.
At the end of the day, always remember we make choices based on the data we have at the moment we make the decision. We only know after if we are right or wrong.
Two simple practices I put in place that usually work well
- Automated testing
Tackling technical debt is costly partly because it involves redoing something that is already working. As we change part of the code, we have to verify we didn’t break the existing feature, or something else.
To make sure of that, we do a lot of testing, which is costly. And what is not detected in the testing process can be very costly for the business.
We have to reduce this risk to a minimum by detecting regressions as early as possible through automated testing as long as it is relevant. From the code with Unit Testing to the user endpoint with UI testing or API testing.
That way, we are a lot more confident tackling technical debt. Those practices can be costly to learn, but the return on investment is far greater.
- The 80/20 rule
When deciding what our team will work on in the next iteration, we ask ourselves the question about how much technical debt we choose to include.
I usually use the 80%-20% number as a rule of thumb. But it can vary depending on the context.
We make sure 20% of the work we are going to do is around reducing the technical debt. The other 80% are all about adding value to our product.
This practice is a lot easier if everything in our backlog is estimated in the same way (e.g. story points), but it is not mandatory.
A couple more insights
Hard conversations
One of the reasons technical debt is a hot topic is because it often triggers hard conversations with parties having different agendas.
My advice here is to always keep in mind that we are all in this together and that sometimes, there might be underlying concerns that have to be dealt with first.
Keep it simple
We tend to make things a lot more complicated than they are. Make sure you keep the main goal in mind and keep it simple!
