“The whole thing goes: The future’s not set. There’s no fate but what we make for ourselves.” – Terminator 2: Judgement Day
If there’s one thing I’ve observed in my twenty years of professional software development, it’s the amazing resilience and long lifespan of legacy software systems.
You would think that software is easy to replace with completely new software. After all, it IS software, after all, isn’t it? Software is a bunch of malleable digital bits … like so much digital play dough, in the hands of a software programmer, you can mold software to be anything you desire.
It’s part of the beauty of software programming. With a keyboard, a text editor and compiler, and YOU, the software developer, you have all the tools you need to build immensely useful software applications that help a company save money, make money, save time, or a myriad of other useful things that help us humans can our jobs done faster and more efficiently.
If you need to change the functionality of a piece of software, all it requires is for the software developer to change the raw source code (the ‘DNA’ of an application) until it performs the desired changes the new functionality requires.
The digital bits and bytes of the application get arranged, and faster than the blink of an eye, you have a new version of your application that contains all the desired changes you intended.
Compared to changing real world things, changing software is a BREEZE.
Yet, despite how relatively malleable and easy software is to change, it often DOESN’T.
Software that continues to exist with little to no changes to its core structure, is referred to as “legacy software”.
In practically every company and government agency I’ve worked at in my professional software career, there ends up being at least one legacy software system that has managed to survive and stick around, and refusing to die or get replaced by something more modern.
That’s the strange paradox of software development. Wanna change the foundation of a real world house or building? You’ve got a LOT of planning, scheduling, effort, money and manpower ahead of you to make that happen.
But changing software should be relatively simple.
Yet it many instances, SOFTWARE STAGNATES.
I worked at a company where a small little Microsoft Access database (think of it as a little Mini-Me version of a real, big iron database from Oracle) ended up being THE enterprise data warehouse for that company.
Microsoft Access was never intended to be designed as an enterprise level product. It was originally intended to be designed as a SMALL database product for a single user (or handful of users).
But that original Access database application never evolved. Oh sure, it was enhanced … over the years, different software developers added additional features here and there.
But the core application and its core architecture essentially stayed the same. I learned this from second hand knowledge from developers who were primarily responsible for maintaining that database application.
And maintain it required!
That single application pulled in more and more developers, database administrators, and other IT staff, until eventually, it required an entire dedicated staff to support it 24/7.
The number one complaint I continually heard from developers and administrators responsible for keeping that database application up and running, basically revolved around how difficult it was to keep it running smoothly. Making software code enhancements to it was also a bear to deal with.
You’d think it’d be a cinch to replace the whole thing was something more enterprise level, right?
After all, it’s all software, and digital bits and bytes, what’s the big deal about replacing it?
And yet, that never happened. This was 15+ years ago, but I’m betting that database application is still chugging along, doing its thing, and requiring an army of developers and other IT staff to keep it going.
At my stint at Bonneville Power Administration, the federal agency responsible for the power needs of the Pacific Northwest region of the United States, they finally got around to retiring a power transmission scheduling system (nicknamed RODS) in 2013. It was originally developed in 1974! As an interesting side note, Bill Gates and Paul Allen, cofounders of Microsoft, pitched in early in the history of RODS, to work on the project.
It took a full FIVE YEARS to fully retire the RODS system with a modern day replacement system.
My current employer still runs their core business on a 35+ year old legacy system that has changed very little over the years. The hardware it originally lived on, big mainframe systems, have of course, been replaced by more modern hardware.
But the core software architecture has essentially remained the same over the years.
I’m convinced, at least based on my own work experience but probably true elsewhere as well, that technical debt and legacy systems go together like peanut butter and jelly.
Does technical debt cause legacy systems? Or do legacy systems cause technical debt?
I think a little of both.
So the $64,000 is WHY do companies and organizations allow legacy systems and technical debt to accumulate?
If software is theoretically easy to change as play dough, WHY do so many organizations let software turn into massive legacy systems that pile on massive technical debt, which in turn, causes the following problems?
- Legacy systems get bigger and more bloated over time
- Legacy systems require an increase in IT staff to keep it up and running
- Legacy systems get more complex and harder to understand over time
- The technology behind legacy systems get older to the point that younger programmers have no desire of learning
The fourth point, is in my belief, the most dangerous point to ignore, in allowing legacy systems to continue to live.
Software code can live forever.
But humans DO NOT.
The reason that Bonneville Power Administration had no choice but to replace their legacy RODS system was primarily the human factor.
The original software designers and programmers behind their legacy system were long retired (or even passed away). If BPA continued to let their legacy system live, sooner or later, there would be one left alive to understand how the original system worked.
As a software developer, the key to staying marketable in the job market, is to keep your skills and technical knowledge as up to date as possible.
The last thing you want to do is acquire a technical skill that is obsolete. First, because learning a new programming language is a major investment in time. Secondly, why bother, when there’s no demand for the skill in the job market?
My own employer is running against the same human ticking time bomb. Sooner or later, they will lose all original developers and analysts behind their legacy system.
I suppose part of the reason why legacy systems are allowed to live so long is related to that old saying, “If it ain’t broke, why fix it?”
But having been responsible for dealing with technical support behind my employer’s legacy system, I can readily attest to the fact that legacy systems cause customer support nightmares when the legacy system goes down.
Soon, everyone scrambles around in a mad rush, trying to figure out who in the organization knows how to navigate the Byzantine legacy system. It costs real time and money out of the company’s coffers to fix legacy system issues.
The SMART CEO or Chief Technology Officer of an organization will understand that allowing legacy systems to continue to exist costs them real world dollars and technical headaches galore.
Yes, it’s not an easy decision to make, but the cost of allowing legacy systems and technical debt to exist will cause future problems that may end up simply too costly and difficult to solve.
