Due to a technical failure, Delta Airlines had to cancel 2,300 flights. The problem was neither in the planes nor the company’s infrastructure. The reason for the chaos, clients' disappointment and the subsequent cut in profit guidance for the third quarter 
was simply aging software.
This article will explain:
- What legacy code is
- Why it is presenting companies with such a challenge
- How we solve such problems
The problem with aging software and legacy apps afflicts every industry, from banking to insurance to telecommunications. The mere presence of aged apps may be a threat to business, with the growing cost of maintenance and administration. As Deloitte states, 50% of insurance companies have chosen to retire their existing Policy Administration Systems due to their age and outdated technology. About 24% of those companies didn’t even consider retiring the aged systems, mostly (81% of respondents) because they see no benefit making such a move.
In fact, failing to see benefits in moving to new technology is a common reason companies keep older software operating, despite the real costs of doing so. In many companies there is a constant struggle between the CTO and CFO, with the former’s eagerness to buy newfangled tech too often met with the admonishment to stick to the “proven and cheaper” solution. The fact is, using outdated software comes with more dangers for business than you might imagine.
This struggle is so persistent in business that even leading high-tech companies and software developers fall into the trap. As a provider of both services and business consulting, we have encountered a fair number of companies that use legacy software (CI/CD) in developing cutting-edge apps.
It may be easily showcased on the CI/CD software development solution.
Keeping your business operational
The problem often seems to be that companies around the world attach greater importance to keeping the company operational than to managing the CI/CD process.
Yet this poses a great threat to business, as aging software is often slow and bloated. With any number of changes of the vision and the crew managing the software, it is easy to allow software to become Frankenware, replete with all the stitches and glitches.
Such patchwork complexity damages reliability, as the software becomes a constellation of patches over time. Constantly fixing bugs inexorably leads to one outcome – collapse--and the bigger the system,the greater the threat.
What’s more, keeping the system operational is both time-consuming and expensive. According to a recent Gartner Study, the money spent on ensuring IT solutions remain functional is growing (70% in 2016 vs. 73% in 2017), while investments in IT are declining (from 20% to 18% on increasing business and 10% to 9% on transforming one’s business). Meanwhile, the costs of running legacy code are continually growing, including for hiring specialists who know how to maintain it, lowering overall efficiency and keeping the growing frequency of failures in check.
Keeping the lights on likewise takes its toll -- constantly fixing glitches in source code is dull, uncreative work. Frustrated with repetitive work with a slight Sisyphean twist, engineers are eager to move on to more interesting work and employers.
Legacy code? How is that possible?
So if legacy code poses such risks to businesses, why is it still so widely used? Departments (including IT) are all too aware that software used in daily business needs to be updated continuously.
But there is significant resistance in tech teams, as the engineers are not eager to leave their comfort zone, facing the same challenges anybody closed in Plato’s cave faces. They may be just so used to the old solution and to constantly fixing it that they see it as an essential component of the organization.
On the other hand, the board may be wary of new tech due to its being “unstable and undertested.” The argument, that “it is proven and it works” is both convincing and misleading, as “just working” is not enough in a competitive environment. Bad code supports emerging fintech startups by making banks inflexible and unable to adapt.
An interesting example of a malicious insider, isn’t it?
Facing the inner threat
Our engineers have faced problems with legacy code enough times to know just how to handle this challenge. Usually, we start by inspecting existing code and analyzing the client’s needs. While this may sound simple, it is anything but. The board and IT teams are usually focused on solving daily problems and may be not up be up to speed on the myriad possibilities new tech offers.
For one of our clients, our DevOps team designed an open-source based solution from scratch, effectively replacing the old tech with no damage to the business processes.
The old tech was patched up to work with modern technologies, be they new programming languages or cloud technologies. Leveraging the power of the network together with the new features was a whole new challenge for the staff, so we also provided support for the technical team.
The new opening
By replacing our old CI/CD with a faster, more flexible solution, our team significantly improved the company’s operations, itself becoming more responsive. What’s more, having our DevOps team prepare the CI/CD solution cut the building time from 6-12 hours to less than four, effectively freeing resources and enabling the team to use its time more effectively.
The new, open-source-based tech was much cheaper to maintain, with no dependency hell and “dark code” buried deep inside. As documentation is rarely as good as we like to think it is, reducing the complexity was vital to lowering the cost of maintenance. Better still, with simplicity comes scalability, as adding new features and optimizing the code was greatly simplified.
In 1950 Alan Turing, the father of computing and the godfather of AI, wrote that machines’ behavior would yield surprises for humans . While we can’t be sure if he was thinking about legacy systems developing their own quirks, it is certain that it was an early warning against building a system that no one can understand, which is precisely--or imprecisely, as the case may be-- what a legacy system becomes after years of tweaking.
