Every software developer on the planet, sooner or later, comes across legacy code.
Legacy code is pretty much what it sounds like … it’s source code for an application that was probably first created long before the current software engineer inherits the application.
It’s actually quite rare for a software developer who gets to work on a “greenfield” project. A greenfield project is one where a software developer gets to write a new application from scratch, and with the freedom to choose any programming language, framework, database and any other technical ingredients that comprise a complete application.
More often than not, a software developer gets hired by a company to join a team who currently “owns” a particular application or system that makes money for the company. It’s the profit that gets generated by that application or system, that helps fund new hire software programmers to join the team and either enhance the application or help to fix ongoing bugs and defects.
Legacy applications often start out as small affairs. I worked at one place where a small little Excel application, designed by a single business analyst, grew in importance as the analyst added more and more scripts and functionality over time.
Microsoft Excel, while very powerful, was never meant to be a primary programming tool for software development.
It does allow customization through scripting and can act as a sort of basic data container. But by no means was it ever intended to act as a full-fledged enterprise database application.
Yet there’s that old saying that when you only have a hammer, everything looks like a nail.
The original business analyst who built that simple Excel worksheet, continued adding more and more functionality to it, and stretching the limits and capabilities of Microsoft’s spreadsheet beyond the point of its original intent.
That didn’t stop that small little Excel application from growing in size. The analyst managed to convince the upper management of that company that her application was crucial to their financial success.
That little Excel spreadsheet, which was originally designed to crunch some numbers, morphed into a behemoth Little Shop of Horrors plant that you could almost hear it say, “Feed me, Seymore, feed me!”
Eventually, that legacy application required a full-time staff of software developers and VERY expensive software consultants, just to keep it up and running 24/7.
I was never part of that software team, which was responsible for the maintenance and upkeep of that application, but I still remember having conversations with the actual developers from that team.
They complained about how archaic and bloated the application became and how it barely held together with duct tape and Elmer’s glue. Having grown over time without any sort of master architectural planning or design, it basically grew into this “FrankenApplication” horror of an application.
It kind of begs the question, why on earth didn’t the company ditch that application for something modern and properly designed?? It could have saved the company the massive labor costs having to employ highly paid software consultants and database administrators, just to keep that thing up and running.
Having been a professional software developer for over two decades, I can honestly say I’ve run into same legacy code dilemma in company after company I’ve worked for.
Applications and legacy systems that should have been retired many years ago, continue to exist and cause maintenance nightmares and headaches for the IT departments that are responsible to keep them on life support, at whatever cost.
I’ve blogged about my own current employer’s massive legacy system which was originally designed well over 25 years ago, and continues to exist to this day. It was originally written in an archaic programming language variant of BASIC. It was designed as a distributed architecture.
Meaning every new customer would have to install and configure their own copy of our software and hardware systems. Which then means anytime you need to release a new patch or version of the software, the company must go through the massive time and effort to update every existing customer … to date, this is in the THOUSANDS.
So why do so many companies allow legacy code and systems to live well beyond their original parameters?
One, if it ain’t broke, don’t fix it! This is probably the most common thinking that many companies and organizations fall into.
Once a piece of software proves itself to be useful and stable at a company, it tends to perch there for a very long time. Take banks, for example. Many banks to this day, still run old mainframe systems running decades old COBOL software.
You would think with all the oodles and oodles of money that banks themselves make every second, they could modernize their IT software and hardware systems at the drop of a hat.
But the longer a piece of software gets entrenched within an organization, the harder it gets from a logistical standpoint, to root it out and replace with something else.
Larry Ellison, the cofounder of the giant database corporation, Oracle, was once famously quoted as saying the secret to his company’s success was that same concept of “entrenchment”. Once companies purchased and adopted his Oracle database product and associated offerings, he could count on the fact that companies found it too difficult to replace his Oracle database with a competing product.
That’s the second major reason why so many legacy applications continue to exist. Executive management deems it too expensive to root out a legacy application.
Which leads to the third major reason which is that your reputation and well being within an organization is on the line, should you make the big decision to replace a big legacy system or application and it causes more problems than it solves. Many executives simply don’t have the stomach or will to follow through with such a major decision.
But the problem with legacy systems and applications is a human one, not a technical one.
When you get down to it, there is no such concept as the “freshness” of source code. Not like a loaf of bread. You wouldn’t dare make a sandwich out of bread older than two or three weeks old, for fear of getting sick from the mold.
But source code is digital. It doesn’t degrade over time. As long as the hardware and the rest of the required infrastructure is in place to run the software, code will continue to run just as fine 30 years from the day it was created as much as the first day.
The problem is human. Code doesn’t age but we humans do. The original programmers of a legacy system don’t stay around forever. They move on to different departments, different teams, they get promoted, they leave the company for greener pastures, or retire.
So the original knowledge and expertise of those original programmers and designers goes with them.
Leaving newer software developers left holding the bag, so to speak. They must try to figure out how the old and original software and systems work and the only way to really do that is by reading the source code.
But as any software developer can attest, no matter how good they are, it can often be difficult comprehending source code you never had a hand in designing in the first place.
Not to mention that if a system or legacy application gets old enough, there simply won’t be ANYONE available who will be willing to take on an ancient legacy programming language or application.
Oh sure, throw enough money at someone, and there will bound to be a few “hired gun” programmers who would be willing to tackle legacy apps.
But as soon as the money and budget dries up, there won’t be any reason for them to stick around and the company ends up facing the same human resource problem as before.
That is literally the “human ticking time bomb” problem my current employer is struggling to address with their massive legacy codebase.
Sooner or later, the ancient system which the company still relies on for its core business, will no longer be sustainable in its current form. There simply won’t be anyone left around from the original team of programmers and architects who built the original system.
So what can be done?
The solution is two-fold. The first step is to move away from the decentralized software model where every new customer has their own local copy of our software applications and systems. It simply adds to the maintenance headaches whenever you need to upgrade or patch the core software.
The core code and applications must get centralized into a cloud-based system which all customers connect to via the internet.
This will be, by no means, a quick and easy task. It will take massive amounts of time, money and resources to migrate every existing and new customer into a centralized cloud-based system.
But it absolutely must be done before you can even think about upgrading the actual source code with something more modern.
Once this first step has been successfully been completed, the second phase of modernizing a legacy system can begin.
An API (Application Programming Interface) layer must be created which will live on top of the original code and database system of the legacy application.
Think of a castle surrounded by a moat filled with water. In the middle ages, this was an ideal way to create a defensible fortress where the only way to get in and out of the castle, was through a common drawbridge which people and animals needed to traverse.
Think of the core data and applications of a legacy system as the castle. The API is the approved “drawbridge” by which any external application or system can gain access to the legacy system.
The API is the set of universal functions and methods that will be the only approved way of retrieving or updating anything from the legacy system.
Once all interested parties agree upon what this API will look like, you can then begin to replace the underlying core legacy data and application that lives behind this API with something modern.
All future software applications and systems which need access to the core data, will go through the universal API.
Again, not an easy task. It will take massive and coordinated efforts by the information technology department of a company as well as the support and backing of upper management, to have any hope of migrating a huge legacy system using this methodology.
But that’s how it usually works in real life. Nothing worth doing comes easy. It always comes with a price.
But given a choice, which would you rather choose? To drive over a shoddy bridge that was built by the lowest bidding contractors because you didn’t want to fork over the necessary tax bonds to fund a properly designed bridge?
I thought so. I don’t enjoy driving my car underwater either.
