Article summary
Technical debt occurs when we knowingly or unknowingly make a decision that will require parts of our system to be reworked later. Maybe we write some messy code in the interest of rapid prototyping and iteration, or maybe we avoid updating a library because it introduces changes that will require a lot of refactoring. We could also simply be unaware of the best way to do do something and learn later that our solution has some negative implications.
No matter how the technical debt arises, knowing how to deal with it can help stop it from getting out of control.
1.Expect It
No team can avoid technical debt entirely, so it should be expected, talked about, and planned for instead of confined to whispers. Refactoring at the end of a feature is normal and expected, but refactoring that reaches back into parts of the code base that you thought were finished can sometimes require extra justification. A team that’s working with a tight deadline might have to fight a little harder to make those changes happen.
If cleaning up technical debt is considered part of the normal development process, it’s a good idea to work that time into estimations. Doing so also creates a culture where people feel safe shining the light on technical debt. No one should be afraid to point it out when they see it.
2. Keep a List
Maintain a list of technical debt, and add to it whenever you discover new technical debt or you do something that increases the technical debt. You can use a project management system, open issues in GitHub, or just keep notes in a text file. Having a list ensures that you won’t forget about anything, and it gets the to-do list out of your head and into a central place so you can focus on other things.
3. Take Care of It with Related Features
Look at your list periodically. If there’s a feature coming up that requires changing a part of the system that you know contains technical debt, try to do some of that cleanup at the same time you do the feature itself. You can gain some efficiency by refactoring code you were going to have to work with anyway, and regular reviews will get you into the habit of continually thinking about how the code you’re working with fits into the larger whole of the system.
On a large project with a bunch of technical debt, it can be useful to schedule periodic meetings where you review and prioritize the list. This gets the entire team on the same page about what’s important and what needs to be done. These meetings can occur on some regular interval or just whenever the list grows enough to warrant another look.
Creating some structure around the way you manage technical debt makes it easier to recognize opportunities to refactor and helps everyone understand what needs to be done. Treat this as a regular part of the development process, and hopefully you won’t find it piling up to an unsustainable level.