#15 Pay It Off: Handling Technical Debt
Taking on technical debt is like purchasing with a credit card. You are borrowing against productivity to get something done quicker or with less effort now.
I am pretty sure that the term technical debt is well-known to you and that you have it in your project or product. We all have it.
There is nothing wrong with it—it’s all about taking shortcuts that allow us to achieve faster results in a given moment. We consciously take risks with the idea of fixing it as soon as possible. That’s it. When we pay it off regularly, it’s fine.
The problem arises when our pile of shame grows, and we do nothing about it.
Taking on technical debt is like purchasing with a credit card. You are borrowing against productivity to get something done quicker or with less effort now.
Just like a credit card, this can provide short-term benefits, but it also incurs interest in the form of additional work needed to fix or improve the quick solution in the future.
What can be assumed to be technical debt? Here are a few examples:
Lacking proper monitoring - you are in a hurry and must sacrifice something. Together with your team, you accept that within the first release, there won’t be a good enough monitoring solution - many areas of your application will lack it. You increase the risk of not spotting errors and suspicious behaviors. You accept this fact and plan to deal with it in the near future
Manual deployment steps - there was an idea to automate the entire deployment. However, you spot a problem that you cannot solve quickly at the moment - first, you need to dive deep into the external component as you lack some knowledge today. The issue is that there is other, more critical work, and you first have to focus on it. You plan to solve it within 2 weeks from now. Until then, one step of the deployment has to be done manually - run 1 script
Low cohesion - you are a part of the startup before the MVP release. You spot that one of your modules combines functionality that is not closely related. Furthermore, you are asked to extend (worsen it further) and release one of the features as soon as possible. You agree with others that immediately after the release, you will spend some time fixing the incorrect modularization
If you forget about the above issues, sooner than later, you will be hit by its consequences:
Lacking proper monitoring - you do not spot issues in the production environment, so you cannot react before your customers notice them. You always have to wait for their feedback. At some point, they become dissatisfied with the quality of the solution and start to look for other solutions. Additionally, you do not see any suspicious traffic, which might lead to data leaks or bring your application down
Manual deployment steps - as there was one manual step in the deployment process, someone else noticed it and decided that he would add another manual step (after all, it’s allowed - there was already one?). Then, another person adds another, and so on. After some time, your deployment process will take 1-2 days instead of 5-10 minutes.
Low cohesion - you add more and more code to the module that should not be a part of it. The database table started to grow and now has 100 properties of a different kind. The module itself contains dozens of checks and validations, often mutually exclusive. This results in poor performance and high maintenance costs. Congrats, you prepared an excellent spaghetti :)
How plan to work on technical debt to not forget about it?
Depending on the surrounding environment, it will differ:
When the development team has complete control over what is included in the scope of work, you work in a great environment. You can continuously plan to rework it, but do it wisely—you can ensure there is always 1 technical debt that someone works on while others work on current tasks and features. Often, we like to fall into the trap of gold-plating the technical part of the solution. In the end, the most important thing is the business value!
When you need approval from someone outside of the development team, try to agree that there is always 1 technical debt item planned to work on (like in the above case). In case this person does not accept it, make sure that you can focus on at least 1-2 technical debt items during the month
When you face strong objections from people outside of the development team, and there is no chance to have any time to focus on technical debt - you tried absolutely everything to convince them - there is unfortunately only one solution - you have to hide it (I hate it, but sometimes it is the only way) and work on it while working on current tasks in the same area. If you do not do that, then at some point, your application will become an unmaintainable monster
The key to paying off the technical debt is to stay regular - until you can reduce more technical debt than it comes, then you are fine.
How do you handle technical debt in your applications?