ALM Practices Part 12: Reducing Technical Debt

What is it?

Technical Debt is every change to your code base that does not comply with the usual level of quality your team has agreed upon. Since this level of quality has been introduced to guarantee a healthy code base throughout the life time of the system, introducing technical debt essentially reduces your team’s ability to quickly add new functionality or to easily find bugs. Examples

• Changing the preferred design for a recurring problem half-way the project without changing the code that was built with the previous design choice. For instance, switching from a UI pattern like Model-View-Presenter to Model-View-ViewModel;
• Copying and pasting code that is mostly the same; a violation of the Don’t Repeat Yourself principle (DRY);
• Choosing a quick and dirty solution to get something done under pressure;
• Not introducing a unit test where you should have;
• Introducing unnecessary complexity were a simple solution would have been sufficient, simply because you try to prepare for the future (which you can’t really);

Why would you do it?

Because technical debt is going to slow you down at one point or another. Whether it is a bug you need to fix at multiple places, a confused new developer that has no clue which solution to use, or incorrectly chosen responsibilities, it will prevent you from moving on. New functionality which should be easy to add, suddenly becomes very difficult to add, either because of a complex design or because you are afraid to break other parts of the system. In addition to that, most systems include a lot of repetitive work or recurring problems. At least consider replacing this with a better solution so that you don’t end up with repetitive maintenance.

What’s the minimum you need to do?

• Create a shared list of items referring to specific issues contributing to the technical debt.
• Add items to that list during reviews, during construction, or when you encounter something you don’t have time to fix right now.
• Allow anyone in the team to add items to that list.
• Prioritize the items on the list so that the ones causing the most amount of pain are at the top of the list.
• Make sure you account for the costs and risks involved in removing the technical debt. Not everything is worth the trouble and whether or not it does depends largely on the specific project and customer environment.
• Whenever you can, try to combine the current activity with small improvements that reduce technical debt.
• Listen to your gut feeling when you have doubts about the desired quality of your code base. Consult a team member or a colleague if you can’t find a better solution yourself.
• Practice Test Driven Development or another automated testing style to maintain a safety net when reducing the technical debt.

What’s the usual thing to do?

• When you start a new project, it is not uncommon to introduce a bit of technical debt in the first one or two sprints so that you can release your first version quickly. However, make sure you schedule tasks to fix that in the next sprints.
• Schedule major redesigns required for reducing technical debt as part of your planning process. For instance, if you’re practicing Scrum, add the technical debt as technical user stories and explain why it this is needed.
• Attach a large physical sheet on the wall listing the top 5 items. For obvious reasons this list is called the Wall of Pain.
• Organize regular (like monthly) brown paper sessions with the entire team to review a part of the code-base to see if the system is still in a healthy state.
• Apply Peer Reviews or Pair Programming to detect and remove technical debt as early as possible.