Getting rid of Legacy Code with Gamification

Get rid of bugs

What is Legacy Code?

There are several interpretations of what Legacy Code is (see Wikipedia - Legacy Code. From most definitions you can normally extract two characteristics that Legacy Code may have:

  • Old. Code that was inherited from someone else or from an old version of the software and that is no longer supported.
  • Ugly. Code that developers are afraid to change and/or isn’t covered by tests.

If it’s just old code, the main problems to tackle are usually complexity, lack of documentation and security vulnerabilities. If it’s ugly, the code is probably causing many bugs (not covered by tests) and frustration amongst developers.

In any case, organizations usually want to get rid of Legacy Code because it’s difficult to maintain and causes a waste of money and resources.

How to get rid of Legacy Code?

When dealing with Legacy Code, people normally find themselves in one of these categories:

  • The Broken Windows theory (wiki). While modifying something within the Legacy Code boundaries, you prefer to follow (copy-paste) the same existing anti-patterns (even if you write new functionality). You don’t feel like changing the way the code looks like since you don’t know where to start from.
  • 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, unaware of what that code does.
  • The Boy Scout Rule. While you are adding a new functionality inside Legacy Code, you take some time and improve it, making it more readable, creating tests or avoiding some future bugs.
  • The Cowboy Way. You decide to go on an adventure and refactor the Legacy Code without thinking too much about the impact. That action 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 code following one of the other approaches above. Finally, after you merge it, you get multiple complaints related to other parts of the system not working as before.

These approaches are a bit exaggerated. But you can surely recognize the four strategies:

  1. Creating more legacy.
  2. Not touching the legacy.
  3. Getting rid of it, a bit each time.
  4. Getting rid of it, 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 or it’s part of the core implementation, you need to wear your Cowboy hat sometimes. If you follow the “Broken Windows” or “Jenga” styles, you have a serious problem and you better deal with it as soon as you can.

Boy Scout Rule

Motivation and Legacy Code

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 get rid of 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.

Get rid of Legacy Code with Quboo

Quboo is a platform that you can use to spice up the process of dealing with Legacy Code by introducing some gamification ingredients. It helps in several ways:

  1. Makes Legacy Code visible to everybody. Quboo uses a score that is based on the amount of technical debt hours, which is directly related to Legacy Code. Therefore, it provides a clear metric and the feeling of progress that developers and managers are missing. For even better results, display the rankings on screens in your office.
  2. Defines a Goal. Set up a date in future to finalize your Campaign for improving Legacy Code. Offer something to the winners as an extra ingredient for fun: think of symbolic trophies like mugs, t-shirts, etc.
  3. Leverages collaboration. 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 kind of tasks end up lost in the backlog.

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.

How Quboo was born and evolved from a gamification experiment to a product

Five years ago, I was working in a project with a huge amount of Legacy Code. That lega...

New in Quboo: Find your Technical Debt

Now the Ranking pages in Quboo include a simple button that will help you find your Tec...
Getting Started
Slack Integration
Sonar Integration
Custom Integrations
Use Cases