Legacy code: 4 steps to master and reduce your technical debt

Legacy projects come with additional challenges for code quality. They underwent many changes (more or less significant) and are probably not maintained by the original authors. Due to a lack of anticipation at design time or complex maintenance, they often have accumulated substantial technical debt. You maintain such an application and want to control its debt? Here I propose four steps to get your technical debt under control.

1. Steady the debt

You may think it’s counter-intuitive, but first, it is essential to focus on current developments rather than fixing past issues. If you plan to reduce your technical debt, you should stop the leak and prevent the creation of new debt. In this first step, you should not consider existing violations and correct new ones immediately.

Linters are very good at giving a diagnosis of the current state, but they do not follow the evolution of the software. So you have to rely on tools like SonarQube, which can display changes since the last analysis or since the beginning of the current development period. Promyze offers a personalized and detailed follow-up to each developer and warns for any violation she made.

Based on this feedback, you can understand that your actions may introduce technical debt. It would be best if you thus took the necessary measures to reverse the debt curve. For example, you can identify commonly violated rules so you can pay more attention to them.

2. Fix priorities

Once you contained your debt, you can start to reduce it. You won’t be able to deal with everything at once, so you have to decide which violations to fix first. The criticality of the rules is an important factor, but it must be differentiated from the priority. The priority can also be set according to the complexity to fix an issue or its location.

Priority according to rules

The first way to set priorities is to consider each rule individually. You will prioritize some rules because they are more critical. It’s more important to fix a potential security flaw than a code formatting issue. You will prioritize other rules because they are easier to fix. Based on the previous example, code can be formatted by tools, thus correcting many violations very simply, while security flaws may require an in-depth rewriting of components.

The ideal is to find a balance so that you can progress quickly and get tangible results. By starting with too tricky problems, you can quickly become discouraged by the lack of change and difficulty, but minor fixes may not seem very useful.

Priority according to components

Another approach is to prioritize according to the location of violations, not the rules. You’ll feel more comfortable fixing issues in a component you know well (for example, because you recently made code editions in there). Also, completely removing violations from a file or a component allows one to observe positive progress and remain motivated.

It is, of course, possible to combine a priority by components and a priority by rules. Thus, you can eliminate code violations of a given rule component by component or inversely eliminate violations of a component rule by rule.

3. Create action plans

Even with the best will in the world, it can be difficult to make a trade-off between new developments and reducing technical debt. To keep in mind the actions to be accomplished, Promyze proposes to create action plans. Each plan corresponds to a development period (its duration is configurable) and can be assigned to a team or a developer; it contains a list of actions to be performed (for example, a fixed number of corrections to perform for a rule).

If you gave priority to some components, an action plan might only take into account actions performed on certain parts of the code. You can therefore customize the action plans according to the priorities set. This way, you can adapt the efforts dedicated to debt reduction at each development period and focus them on the parts that need it most.

4. Monitor KPIs

Finally, don’t forget to monitor KPIs (Key Performance Indicators), such as the number of bugs, violations, etc. It’s important to observe positive effects from your efforts and tracked the value provided throughout your ongoing developments. KPIs ensure your technical debt is reduced. You can also check the impact on current developments to avoid slowing them down.

KPIs will help you adjust action plans. If the debt is not decreasing fast enough, you can create plans that require more effort. If the effort to correct the debt is getting in the way of other tasks, it may be necessary to reduce the scope and create lighter action plans.

Summary

Controlling and reducing the technical debt of a legacy project is not an easy task, but it is possible to obtain results by proceeding iteratively. It is first important to stabilize the debt and then set priorities to move forward step by step. Action plans will allow you to implement these priorities, and KPIs will help you balance them.