What is legacy code? Is it good for you?

U. Rinat
Engineer’s Notes
Published in
5 min readMar 26, 2017

--

It takes a special mindset to effectively work with legacy code. The skill of taking a pile of shit and making it into something that everyone would want to eat again is invaluable.

To the most developers “legacy code” means crappy and tangled code. Bad code is definitely a property of the legacy codebase but absolutely not a definition. So what is that ugly monster we call legacy? Let’s dive right into where it lives with some examples.

What is legacy code?

Not a single project starts as a complex scaled system. The very first step for for every idea is to build a proof of concept (PoC), to check the water, to make sure that idea is worth investing your resources into. Going with positive momentum, lets assume that the idea was brilliant and PoC was successful. Now your PoC application starts gaining customers who love your product and recommend it, the user base grows exponentially to the point where application can’t take it anymore. Which is a clear sign that it’s time to actually start invest into your application.

It’s time to start restructuring your monolith or build a completely new platform from scratch and gracefully migrate your users from one to another (everything is doable, complexities vary). It doesn’t matter which way you will chose to go, what matters is that your first PoC application has now become legacy, meaning old and most often sloppy code that you have to work with, patch and maintain for some time.

Presence of legacy code is generally a great sign of the evolution in your company. Most often it signifies growth and a lot less often it tells about complexity of the domain and need for constant adaptation to changing market requirements which is a different topic.

We talked a little bit about growth and evolution from PoC application to a complex (and probably distributed) application to satisfy your business needs. But what about applications that were initially built as complex and distributed enterprise solutions and were already meant to support operations on the global level? Can those become legacy code?

Yes and absolutely. Nothing stays the same. Everything is evolving and changing, including software. Some systems (due to a heavy burden of legal regulations) can stay at the same place for a long time, but everything else is jumping, leaping forward faster than you can imagine and if you can’t keep up then your software begins to rot.

New discoveries are happening every second, markets change, vulnerabilities are piling up, platforms evolve. If at some point active development (versioning) of a software stops, it automatically switches to maintenance mode. Once software enters the maintenance phase, it becomes legacy, it becomes old.

There are a few exceptions to the legacy title, a software can still have this title, even though an active development (and versioning) is still happening. This happens mostly in large companies that don’t build their platforms themselves, that chose “buy-and-integrate” path. In this case you are roughly bound to a single version, and sequential upgrades can be very pricy and largely avoided. In this case integration developers in those companies continue working in maintenance mode and purchased software becomes legacy from the point of view of that particular company.

Working with legacy code. Is it good for you?

Yes. Experience with legacy code is a must. Everyone is capable of working in a fresh environment where everything is new and shiny, but working with legacy is a really difficult task that creates new mindsets and rewires brains.

100% percent of developers I have talked to, hate it! They can’t stand legacy code and if there is a sign of the maintenance phase, they will run in the opposite direction like there is a fire. Which is expected and understandable. Working with legacy code is not easy at all. It takes special knowledge and experience to navigate through rotten code while making defensive changes with surgical precision.

As mentioned above legacy code differs from company to company, and in those cases where legacy code is a base for the future application, it is a great opportunity for you to exercise your refactoring skills, learn new practices and best ways of approaching very hard and often tangled pieces of code.

Refactoring legacy software differs a lot from refactoring your single class that you wrote a week ago. This is the case where extreme attention to literal details (praised by so many..) can cause a tunnel vision and actually bring harm. This is where you will learn how to exercise the balance in attention between bigger picture of a system as a whole (keeping in mind closest destination point of the refactoring, closest milestone) and small details, small changes. You can’t just be focused on one part of the system you need to learn and know all internal and external APIs and communication routes inside out. Why? Because of the fragility. Even a tiny change in legacy code, especially code that you are unfamiliar with, can cause and chain reaction of cascading breakages.

But this is an extreme case with quite old (last major release 10+ years ago) and poorly maintained systems. If you working with a fresher application, there is still a lot to learn and most importantly to get the satisfaction from. If you clearly see an outdated code, that was written by you, it’s a clear sign of your personal development and evolution, for me it’s quite satisfying. And when working with larger systems you can recognize quite complicated engineering decisions that were made back then, and see the patterns, and draw your parallels with current trends.

Most importantly legacy software is where your get the most of your domain knowledge from. The need of extensive reverse engineering (due to fragility as described above) gives you a lot of information about the domain this software was built for and marketing decisions, requirements and even regulations.

To conclude, just want to repeat that experience with legacy code is absolutely necessary for every developer. Never forget that there are lessons and learning opportunities everywhere, just tune in and keep your eyes open and learn to recognize those.

If you found this article useful please click on the ❤ below to help me spread the word.

--

--