Photo by Max Duzij on Unsplash

You Will Never Get Rid of Legacy Code

Emanuel Marques
May 22, 2020 · 5 min read

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

Photo by Alice Pasqual on Unsplash

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

Photo by Sharon McCutcheon on Unsplash

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.

Respect your legacy!

A typical personal piece of advice that also works in your attitude regarding legacy code: respect the code that made a company/project grow. Developers that are new to the company or the industry often laugh when they know that a big company has so poorly written code. “How is it possible? How comes that XPTO Software has such bad code?”

The answer is: because the “legacy applications” served its purpose. The presented a solution to the market that had a good response — something your new, state of the art, all good patterns microservice application still needs to prove. Don’t judge other people’s code. You don’t know the circumstances in which it was developed.

Photo by Markus Spiske on Unsplash

Thank you for reading my article. If you want to receive updates regarding my latest work, subscribe to my email list.

If you have any questions or subjects you would like to discuss further, please leave a response. I’ll be happy to talk about it!

The Startup

Get smarter at building your thing. Join The Startup’s +785K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Emanuel Marques

Written by

Software Engineer, fascinated by the impact of technology in our everyday life. Writing about Tech and Personal Development.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +785K followers.

Emanuel Marques

Written by

Software Engineer, fascinated by the impact of technology in our everyday life. Writing about Tech and Personal Development.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +785K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store