Dealing with Legacy Code (but Don’t Call It That)

It’s not always a good idea to label a customer’s codebase ‘legacy code’. Experienced managers tell us that the tem “legacy code” has negative connotation, so it’s better to call it something like “existing codebase”.

Frankly, I’m not sure that “legacy code” has negative context in the eyes of the code owner or not. But it definitely has one in the eyes of developers. However, it also has a pragmatic meaning. This is what I would like to talk about.

What is Legacy Code?

Legacy code is simply code which has parts that are new to the current developers. If the code owner changes the team of engineers, the new participants will call the codebase ‘legacy code’. But, in most cases the term legacy code refers to code that has old, or sometimes very old.

Regardless of whether the code is good or bad, it becomes legacy code when the team of engineers changes. Sometimes an application may become legacy even if the team remains the same all the time, but the codebase is evolved over years and years of development, or is not updated at all for long periods.

The Urge to Start From Scratch

Developers frequently want to rewrite everything. They tend to dislike what they have written a year ago. Not to mention, they often dislike solutions developed by other people.

An urge to re­create the whole project is natural to people of their profession. Software developers always prefer working with robust, clean code. However, the project owner usually has a more practical mindset. He can make the decision to refactor from a business perspective, so it is up to him whether to follow intentions of the engineers or tell them to continue working with the existing solution.

My personal experience shows that it is usually possible to work on a legacy code, even a very poor one, and get remarkable results.

The Need To Refactor

If you are a legacy code owner, the most important thing you may need to understand is that it requires some updating. Developers may not be able to explain the importance of this procedure because of two reasons.

1. Refactoring doesn’t make sense to the customer if nothing seems to be broken. We even consider it a risk when an engineer speaks about refactoring to the customer who does not have technical skills.
2. Code refactoring is not apparent from the outside. Engineers may do amazing work and be very happy with the new state of the code, but the results may not be obvious to their customer.

So, a little bit of understanding of the problem on the part of the customer may help the engineers to have some freedom in terms of making the code cleaner.

How to Approach Refactoring

In order to help non technical project owners understand special aspects of refactoring, here is a procedure most of mature software engineers will stick to when they get a project from another team of developers.

Most likely, they will start from making a code review. Special attention will be paid to automated tests. If tests do not pass or if there are no tests at all, the project will be considered legacy code of the worst kind – questionable quality.

Automated tests are more than just code which verifies other code. They are a comprehensive description of the application. Lack of tests means lack of knowledge. No tests means almost no clear knowledge about what the application is supposed to do.

New developers may get discouraged if a project has broken tests or no tests at all. Still, there is a way to deal with it and do it in a professional manner. If new developers take over your project, their next steps would be (approximately):

1. Removing all failing tests without even thinking about what they are for. After this step one should have a non comprehensive test environment, but all the tests should pass.
2. Now when they move to a particular part of the code which does not have tests, they start writing tests for it. They will describe how the application works instead of describing how it should work (what happens in a usual test driven development process) and use so called “acceptance tests” which are very similar to step by step use cases.
3. At this point the developers will need help of the project owner. To write some use cases, they will be asking the owner about how the application works. When knowledge is lost, the only way to restore it is to rely on the customer. Communication is the key.
4. After tests are developed, they will be able to refactor the code. One of automated tests functions is to allow software developers to be aware when they break the current application behavior.

Cleaning Up

Now your developers can clean up the code part by part. The procedure will be different if the application has a “good legacy” code or the project turned legacy with time. But one way or another, refactoring of legacy is a good fundamental input.

Do not consider it as unnecessary work just because your previous developers did not recommend it. The may have understood the code in their head, but new developers won’t have that background. New developers are, however,  much better in pointing out doubtful parts of the code and restoring the knowledge when it is lost.

And even if the procedure looks time consuming, your code will benefit from it cardinally.