What makes any source code a legacy code? A question that occurs every now and then in the software industry. It usually and commonly refers to an older piece of software/code that is no longer supported or maintained.

Legacy as a term means something that is old. Something from the past that someone else left for the people behind to inherit. It can also refer to traditions that someone left behind for those who follow to continue to adapt and practice.

But If you look closely. In the software industry the word legacy code to engineers has some serious implications. It usually means that the code is no longer worthy of investing the time and effort into it. Or no longer relevant to modern architectures, patterns, or practices.

It all makes sense. Because the software industry doesn’t respect tradition. It questions everything all of the time. You can see it very clearly in the rise and fall of the technologies that used not so long ago versus what we have today. Cassettes were once the medium for audible content. Today is ceases to exist with the rise of digital content. Phones used to be the most modern communication devices. Today they are replaced with instant messaging and video calling in addition to VOIP communications.

Give that the software industry is always evolving. Growing and changing exponentially and rapidly. The observer might learn one simple and obvious truth in this industry, which is the fact that nothing stays the same, and nothing in this industry is meant to live forever.

This is where the topic of legacy code becomes a more pressing issue to understand and analyze. A better understanding of what legacy code is, and how to deal with it will help us continue to evolve and achieve better and bigger goals in our quest for perfection as engineers. And our journey as humans towards the survival of our kind and it’s evolution.

From The Top
Let’s start from the beginning.

If legacy code means old code. And old code is an outdated effort in the software industry. Then legacy code is a piece of software that is subject to renovation and re-implementation.

Legacy code is a tradition of engineering standards, patterns and technologies that are no longer followed or no longer supported. Legacy code is also not meant to be framed and hung on a wall for people to look at. Unlike art, the older the code may be the less valuable it becomes. That’s simply because our ways of solving problems and tackling older issues with modern approaches continue to evolve. And with this evolution in the industry everything from the past becomes obsolete. Merely an indication of a previously successful attempt that may or may not influence modern approaches to solve the same issues.

This rapid and aggressive expansion in the industry is what makes it quite attractive to younger and hungrier minds that don’t mind giving an older problem a go with a newer approach.

This is how the software industry continues to be more and more relevant across all generations. It doesn’t respect what was. But it focuses more on what is and what can be. It forever changes it’s colors, skins and shape.

With all of this mind, any piece of software could become legacy as soon as a new pattern, architecture or technology emerges and proves itself to be more effective than the existing methods, patterns or technologies.

If a legacy code is a code that is subject to change, then any code out there shall become legacy as soon as it hits production. That’s how fast the industry changes today. That’s the mindset every engineer should have to drive innovation.

Driving Forces
There are two forces that drive engineering in the software industry. The desire of completion and delivery. And the desire for innovation and prosperity. Wherever I worked, and whenever I had the discussions with engineers they’ve always been leaning harder towards on force or the other. Some engineers are mad scientists, they dig deeper into the way things are built and try to innovate every single step of the way. Some other engineers are more focused on delivery. They use existing methods to drive a value as soon and as fast as possible.

You need both of these forces in any engineering team. The concept of systematic innovation mandates a demand for mad scientists on every team. But madness by definition can get out of control. It can halt an entire project searching for something as simple as coming up with a new regular expression to valid emails. This is where the cowboys of engineers come in to balance the equation. They keep the mad scientists focused on the path, while the mad scientists innovate a better, fast and more maintainable way to solve the same old problems.

I have observed that the mad scientists will shake things up to drive evolution, while the cowboys will try to calm that angry beast of desire to evolve to a point of stabilization to reach the other end of the journey.

On The Bleeding Edge
In order for a team to systematically incorporate innovation in their day-to-day engineering process, they must continue to live on the bleeding edge of technology. They must incorporate a tech-radar task where every team member takes on the lead of discovering newer technologies and modern patterns to solve existing problems.

A part of living on the bleeding edge is to build on top of experimental beta or alpha releases of other technologies. This way the developing teams of these technologies can get the fastest feedback on their products, while the consumer teams get the benefit of learning and build on top of the latest and greatest technologies. This way both teams enrich their experiences and empower each other to achieve more.

Living on the bleeding edge guarantees that the only option to evolve is to continue to learn about the latest and greatest in the industry. With the mass adaptation of software engineering in our modern day there are thousands of ways to achieve the very same goal. These ways are a call for analysis, study and research to find the best befitting for the project, the team and the culture.

Alarming Trends
You might have heard the saying in our industry: “If it works don’t fix it”.

This saying is the epitome of a devolving mindsets that settle for less. These are the very same mindsets that cost corporates millions of dollars on costs of support and bug fixes instead of solving the root cause and taking the risk of innovation.

It’s a mindset problem. For some, a running software is just a job. Something to do for 8 hours and that’s it. The goal for some is to find the easiest way to spend those 8 hours with the minimum amount of effort possible to get a paycheck.

But the right way and the hard way are usually the same thing. Some engineers will find the most creative, innovative, and productive way to spend those 8 hours. They are not some clock-watchers waiting to burn time to get a paycheck. They are the visionary vanguards who are willing to go the extra mile to pave the way of innovation for those behind them to follow their footsteps and go further faster.

Legacy Types
Legacy code/software isn’t all the same. The further any software stays in the legacy state, the more likely it is to become harder to modernize. It’s just like health issues. The longer you ignore it the harder it becomes to treat. And so is the case with every issue in our world. The majority of our issues won’t just go away by leaving things as is. An intentional, conscious and systematic renovation that is frequent enough to keep a system above the water when it comes to its legacy status is what’s needed to keep a system in somewhat maintainable state.

With the rate of technology change today, a system that has been left in the same state for a year for instance might require a much larger investment in modernization than one that has been left for a couple of months with no renovation.

The complexity of the system also plays a huge role in it’s legacy state. A simple website that needs to go from PHP 5.0 to PHP 7.0 as an upgrade could take much less work than an entire monolithic enterprise system that needs a full reconceptualization process.

Some stakeholders or non-technical investors think that leaving things as is, then requesting an upgrade or a new feature 3 years later would cost the same for any given software. And this is where the true gap in communications come into play. The older the software becomes the costlier the price would be to give the system an upgrade or add a new feature to it.

But the complexity is only one side of the story. The technology or the framework supporting the system will also inevitably change. And with that change a new security issues might arise that will not be covered in older versions of the same framework. It becomes a huge vulnerability to all the existing systems running the older versions but also are unable to upgrade due to how far the current version is from where the system is. I have witnessed situations where an upgrade was required for a platform running the .NET Framework version 3.5 to move to .NET Core. If the system on 3.5 would have been regularly and systematically upgraded to the latest and greatest a situation like this could have never happened. At least not with that cost.

People Over Profit
It’s really all about the people building the software. A continuously evolving software gives the engineers working on that software the opportunity to learn and grow. Builds the muscle for them to innovate and systematically approach every problem with an evolutionary mindset. Seeking the betterment of everything it touches.

Keeping a system up to date with the latest libraries or frameworks gives younger generations of engineers the change to contribute to a project from Day 0 without having to risk any major issues. These simple and yet important chores build confidence in engineering teams and ensures every single member on the team is carrying their weight into a successful project.

If legacy code calls for modernization. And modernization calls for curiosity and knowledge. Then legacy is just the trigger that alarms the engineers and reminds them to continue to learn, evolve and grow.

Now or Never
We can safely assume that every single piece of software that you’ve ever worked on till the moment you are reading this article is considered legacy. And now it’s our responsibility to keep the software we care about above the waters for as long as we are required to maintain it. It’s the best way to extract value and learning from a code that is running in production.

It’s the same difference between proactionary and reactionary engineers. Don’t wait for your software to become a legacy before you take action o it. Continue to use it as a learning platform that benefits both the software and the engineers learning, exploring and evolving with the system as it lives.