Fixing Legacy Code

4 minute read

Legacy Code Timeline

Fixing Legacy Code

First, let’s clarify that, when I refer to Legacy Code, I don’t mean code that was there before you joined the company but I follow a modern interpretation of it: code that does not have tests or that is hard to work with.

When it comes to fixing Legacy Code in your Software Project, it’s important that you define how you want to approach it, no matter if it’s as a team or at organization level. Otherwise, you take the risk of not doing it at all or doing it the wrong way, causing even more trouble. Let’s see why.

Strategies to Fixing Legacy Code

I like simplifying the strategies to fixing (or not fixing) legacy code in four groups:

  • The Broken Windows. See this link for the Theory. Maybe you don’t know if that existing code is error-prone or not, but you follow the same anti-patterns for new functionality, because you don’t feel like changing the way the code looks like.
  • Jenga Development. Whenever you need to add new functionality, you do it nicely but you leave the old code as-is. You are in a cold sweat, trying not to touch those code blocks because they have no automated tests and you don’t want to take the risk of breaking existing functionality unawarely.
  • The Boy Scout Rule. While you are there adding a new functionality to some ugly code, you take some time and clean it, making it more readable or avoiding some future bugs. As a proportion, you use up to a maximum of a 20% of the total time making existing code better.
  • The Cowboy Way. You decide to go on a quest to refactor the project. That implies massive changes across multiple packages/classes/modules. It takes two weeks before you have something that works as before. When you’re about to merge it, you need another two weeks because others have been merging new functionality on top of that horrible code creature.

These are exaggerations, of course. But you can surely recognize these strategies: creating more legacy, not fixing anything, fixing a bit each time, or fixing all at once.

The Boy Scout Rule is clearly the best technique, but sometimes is not enough. If the technical debt that is slowing you down is spread across your codebase because it’s part of the core implementation, you need to wear your Cowboy hat sometimes. But, if you follow the “Broken Windows” or “Jenga” styles, you have a problem and you have to fix it as soon as you can.

Boy Scout Rule

What if you help the Boy Scout?

As a software developer, the feeling of not having to deal anymore with error-prone code is great. Your scripts or classes look good and readable. Nobody needs to waste time anymore in explaining how that old code works, or testing features manually, or fixing bugs caused by the technical debt.

However, even though the final result gives a boost of motivation, the process of getting there is not so encouraging. To accomplish it step by step, you may need to introduce some tricks here and there or have a partially-fixed codebase that may look even worse than before. Furthermore, you need to have a clear commitment that you will finish the refactoring task or the team will feel that they are wasting their time.

Quboo helps you create a Roadmap to Fixing Legacy Code. It makes the refactoring task a team effort and it encourages everybody to get rid of that anchor that is dragging the team.

Using Quboo to pay Technical Debt

Quboo is a free, open source tool that you can use to spice up the process of paying Technical Debt by introducing some gamification ingredients. It helps in several ways:

  1. Make Fixing Legacy Code visible to everybody. You need to make sure to get management on board by explaining the main advantage of getting rid of technical debt: increasing development velocity. Besides, Quboo uses scoring that is based on the amount of technical debt hours so it provides the feeling of progress that both you and management are missing. Make it also literally visible: display the rankings on screens in the office.
  2. Define a Goal. Quboo Reward First, set up the game parameters by having a look at the Points and Badges documentation. Then, establish a date in future in which you’ll give a reward to the Winner Team. It does not need to be a big reward: think of symbolic trophies like mugs, t-shirts, figures, and other gadgets. If you want to focus on a specific problem, tell everybody what are the parts of the code in which you want to put more effort.
  3. Announce what you want to achieve. The fact that you are supported by a lightweight game is a powerful way of getting together to fix the problem. Without the game, this collaborative task may end up lost somewhere in your backlog or not even defined.

However, it’s important that you don’t cross any of these lines:

  • Don’t make it too serious. If fixing Legacy Code is critical and you have a hard deadline that you need to meet, don’t use this game. Make it the top priority in your roadmap and define a plan of action instead.
  • Don’t disguise it. Quboo, and gamification in general, is not intended to manipulating people to do what you want. Make clear to everybody that this game is just to try to have fun while doing these boring tasks.

Once you finish the first iteration, check with everybody how was the experience and, if you want to try again, define a new goal and start back again. You can re-define the Legacy Date if you need it, and restart all the scores so everybody can catch up. You can do that by using the corresponding options under the Settings section from Quboo’s web interface.