Technical debt is something that every dev team has to manage. Often it is treated like something to avoid at all costs, but in the real world, that is not possible. With the fast-paced development cycles, it is sometimes necessary to strategically add technical debt to fit business needs and timeframes.
The trouble comes when teams don’t pay off the technical debt afterward. If technical debt starts compounding, it can be increasingly difficult to make progress on it, and it’s easier to “just let one more thing go.” So once you recognize an increasing built-up in technical debt, it’s essential to react correctly and deal with it!
The first step when tackling technical debt is knowing exactly where the technical debt lurks. It may seem like a waste of time, but setting some time aside to review your codebase and document all the areas with technical debt, it will be much easier to make a plan of attack. When documenting your technical debt, you don’t need to spend a significant amount of time with the details, but it should be clear what and where the issues needing to be addressed are.
Effective Code Review
Once the technical debt has been documented, the next thing is to stop new technical debt from haphazardly entering the codebase without group consensus. The way to do this is by implementing an effective code review process. Having one or two extra pairs of eyes look at a piece of code can often spot potential technical debt and just overall help increase code quality for new code interesting the codebase.
When establishing code review, it is crucial to make sure the reviewers feel comfortable pushing back on code changes and call out the technical debt they see. This is important because a rubber-stamping review process will give little value, reduce your code base’s code quality, and waste valuable development time.
Finally, when all the technical debt is documented and little to no new technical debt is entering your project, the final step is to remove your identified technical debt slowly. Most of the time, you won’t have time to tackle all the technical debt all at once, so it is essential to work on the high-value technical debt first and make small improvements to the project incrementally.
It takes commitment to remove technical debt from your project and often weeks of continuous refactoring small chunks of code. This step relies on making smart refactors and effectively getting rid of the technical debt incrementally. It won’t happen overnight! Refactoring itself is an art form, so if you want to get a better grasp of it, I’d recommend this book on refactoring.
Every team has to deal with technical debt, consciously or not. Some approaches are well thought out and use technical debt strategically, and some don’t consider the trade-offs at all. If you are in the latter category and want to get out of that debt, following the steps above will give you a good shot at getting and staying out of technical debt going forward!