Technical Debt: Deal With It
I think there are no technical teams that do not have technical debt. Good teams have a limited amount planned for refactoring in the nearest future. Not-so-good teams may have a dept that will take a couple of years to get rid of. Let us see how to live with the second situation and turn it into the first one.
Why So Messy?
I want to start by explaining the reasons why technical debt appears at all.
The first reason is the lack of discipline inside the technical team. If the team can not agree on the architecture, best practices, and tools, then there is a high chance they will need to adjust the solution constantly.
The second and third reasons are poor code quality and missing code review. These are consequences of missing discipline. They lead to a mess on a code level, overcomplicated implementation, and high estimates for complex features.
The last reason is the inability to show the business value of a proper implementation to the business team. If you can not explain why good code is a must-have thing then you will never have a chance to write it.
The first three reasons are strictly technical, and there are many materials and tools to improve the situation. The last one, however, is business related, and many technical specialists can struggle here. The following chapter shows how to explain why you need to get rid of technical debt to the business team.
Business Value
There are many ways to persuade a business team that technical debt is bad. The primary argument is that reducing technical debt has a business value. Here are examples of areas where it is easy to demonstrate that.
If the product has any amount of R&D then you can say that the implementation takes less time when you do not have technical dept. Proper architecture, code quality, and automated testing are perfect time-saviors.
Similarly, if you have healthy code then maintenance and support are significantly easier and faster too. The better the quality of the code, the fewer errors are there.
Another technical argument can be the maintenance cost of good architecture. Good architecture is flexible and stable, so adjusting it to new business cases or requirements takes less time.
Finally, you can present each decrease in technical debt as a business feature. You can show code quality metrics and predict how they affect the implementation time of the current and future features. The more time you save, the happier your business team will be.
Refactoring, Refactoring, Refactoring
It is a part where developers can finally do what they can do best: write the code!
Refactoring is the best tool in the technical toolbox for technical debt reduction. I am not going to talk again about hundreds of refactoring best practices. It is better to read Martin Fowler’s Refactoring guide and use whatever recommendations are suited to your case.
You should also present refactoring as a feature to show the business value of the refactoring. Code quality metrics and time savings for future features can be good representations of the project's business value.
The final thing you as an architect or a developer can do here: do not allow technical debt to rise again. You have to use automated tools to prevent bad code from appearing in the project again. You can also introduce periodic architectural and code quality reviews to maintain proper code quality.
No matter how you achieve that, no technical debt means you do not need to fight old problems. Instead, you have time to concentrate on the implementation of requirements and do your job perfectly!