Most of us have been there. Your company wants to re-do some of its components using the latest technology/architecture/patterns/rules/you name it. They say: “We need to kill legacy.”
But what is this, really?
According to Wikipedia, legacy code is:
“Code inserted into modern software for the purpose of maintaining an older or previously supported feature.”
In other words, code developed in different circumstances, to support an old feature that is part of your product.
In reality, the most common cause for this to happen is when reality changes. Software is developed, taking into account several requirements for each feature. These requirements are essentially from two types: functional and non-functional. The first type tightly connects to the business you are in. It reflects what your product is supposed to do, describing business rules and restrictions. The second type links to restrictions that are related to the environment of your business. It refers to problems such as availability, security, performance, and reliability.
When looking at these two types of requirements, it’s easy to see which one is more subject to change. As your business changes, your product also must change. Usually, this leads to changes in code that you initially didn’t think of, and causes it to have a more flawed design than you wished.
Legacy code creation is directly proportional to the number of change requests that you get
This relation brings a question: “If that’s true, how do you kill legacy when you’re in a highly volatile business?”
Quick answer: you don’t. 🙂
In this case, it is common for the business to change more often than you develop your product, which leads to having new features that are born legacy.
If your product serves a highly volatile business, you don’t kill legacy. You manage it
Managing legacy
A legacy-free product is a product that serves no purpose. We all need to remember that software only exists to support specific business needs and that those needs will change. Frequently. That’s why the only software that can be legacy-free is the one that serves no business.
As much as you try, you will always have your fair share of legacy code. And that’s a good thing! It means that it is useful enough for someone to need a change.
Isolate your legacy code
Legacy code is typically code that was already tested in the most challenging environment of all: production. It usually means that those features are stable and solve the problem, as described in the first requirements.
Avoid keeping maintenance on that code. If new requirements arrive, only then consider the migration to a new service.
Understand the value of those features
And I mean money-wise. Not personal or emotional value. If it is a significant part of your income, it may be worth the time to rethink how it should be implemented. But it’s common for the legacy features to have more costs than benefits. These costs increase even more when you take into account the maintenance costs. In this case, the best you can do is to set a date for that given feature to be deprecated. After that date, delete the code that is no longer used. Otherwise, it will cause entropy. And if you need it, you still have it in version control.
Legacy Code vs. Technical Debt
These two concepts are often mistakenly used. It is common to hear someone saying: “I hate to work in the application X because it is legacy.” This accusation is hardly true. A legacy product doesn’t necessarily have a poorly written code. One thing is an application that supports an old feature, designed for another reality. Another is an application that has lousy code, hard to read, and with dependencies all over the place.
But why are those concepts so often connected?
Since 2008 we’ve seen a boom of startups rising from nowhere. Everyone went wild, implementing their ideas, and trying to put them to the market. “The early bird gets the worm” is an old proverb.
Most companies were competing with time itself and needed to put their product live as soon as possible.
Rush is the enemy of perfection
The business needs require any startup to have their products shipped before there was any time to think or evaluate possible alternatives to the fastest solution. It led to most MVPs to be shipped without much attention to code quality, especially when it comes to readability and scalability. There were other priorities in the game. That’s why most legacy products (which are common to be the company’s MVPs) are full of technical debt.
But slowness is enemy of objective
However, this is needed for a company to survive. As I mentioned before, any software is just a tool that supports a business. We should never forget that. If these startups didn’t place their products in the market as fast as they did, they would probably not be here anymore.