Cobol abstract concept blue text blue background

Technology Escrow

The Scary Consequences of Legacy Code

  1. Home
  2. blogs
  3. The Scary Consequences of Legacy Code
Legacy code – yup, it’s still around. But, the scary thing is, it may still be running your business. Traditionally, legacy code has been defined as…

Legacy code – yup, it’s still around. But, the scary thing is, it may still be running your business.

Traditionally, legacy code has been defined as source code that relates to a no-longer supported operating system or other computer technology. More recently, however, the software engineering community has interpreted the term to include: source code inherited from someone else and source code inherited from an older version of the software. In any case, legacy code can cause problems.

Where is legacy code most prevalent?

Let’s start by looking at the system that runs most airlines reservation systems, Sabre. Although the company has launched new, innovative technology, it is the airline’s choice to upgrade or continue with legacy reservation systems. As if there haven’t been enough crises with airlines lately, another threat lurks within the legacy code.

According to Greg Leffler, Senior Editor for Software Engineering and Technology at LinkedIn, “airlines rely on these legacy systems for nearly every function involved in flight, from reservations, check-in, and cargo accounting all the way to filing the flight plans, calculating fuel needs, and providing pilots with the preflight paperwork,” which is why legacy code can cost you billions. He explains that “beyond the direct monetary costs, there are also the costs associated with loss of customer goodwill, decreases in stock price, the increased difficulty recruiting technical talent, and more – all of which can easily multiply these costs.” He raises questions around disaster recovery drills, testing performance and failover.

The original Sabre system and many other business, government, and financial systems, were built using COBOL, the Common Business Oriented Language designed in 1959 based on work by Grace Hopper as part of a US Department of Defense effort to create a portable programming language for data processing. Although revolutionary for its time, COBOL has for the most part been replaced by programming languages such as Java and C. However, programming in COBOL is still required to maintain existing applications on mainframes.

COBOL is also often found in many government applications. FedTech reports, “Roughly 80 percent of the $90 billion the federal government spends annually on IT is dedicated to operations and maintenance of legacy IT systems.”

“The stakes are especially high for the financial industry, where an estimated $3 trillion in daily commerce flows through COBOL systems,” explains a Reuters article. The language underpins deposit accounts, check-clearing services, card networks, ATMs, mortgage servicing, loan ledgers and other services.

So, why is COBOL still being used?

The commonly quoted adage is, “If it ain’t broke, don’t fix it.” COBOL applications still work and they are reliable, plus rewriting all that code would be hugely expensive. It was estimated that as recently as 2015, Britons interacted with COBOL an average of ten times a day – from using an ATM machine, to waiting for a stoplight, to shopping online.

HackerRank reports the biggest reason “not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records. Creators of COBOL invested 2 trillion dollars for the universal language. Businesses worldwide run on over 220 billion lines of code today. It would be a herculean feat to replace every single business program with a brand new language without introducing detrimental bugs. Hence, the cost just hasn’t outweighed the benefits of replacing COBOL.”

But, what are the risks of doing nothing?

Legacy code invites quality and security issues

Recent research by Vector Software shows that “almost half of those questioned have 50% of their software built on legacy code bases which continues to be a barrier to quality.”

A recent academic study, “Security Breaches in the U.S. Federal Government,” hypothesized that federal agencies with legacy systems are more likely to experience security breaches. The findings of the study support the hypothesis, showing that legacy IT systems create grave vulnerabilities in federal IT infrastructures, which cybercriminals can easily exploit. This suggests that modernization of legacy systems is one of the key mitigation mechanisms for the IT vulnerabilities.

A hack like the recent one that caused the Dallas emergency sirens to simultaneous blare overnight, demonstrates that old, insecure systems can cause serious security issues. This could have been a prank, but it also could have been someone trying to prove a point about our infrastructure. The sirens caused an influx of 911 calls, which caused wait times of up to six minutes. Other software glitches related to 911 calls have resulted in two deaths as callers waited up to 30 minutes for a 911 response.

How do you safeguard your legacy systems?

The need to maintain legacy code and keep it operational has led to discussions around the need for COBOL programmers. Some companies are looking to entice experienced professionals to continue to work on COBOL projects. At the same time, IBM is teaching new coders COBOL and is working with universities to develop a curriculum that includes COBOL programming, a language that most universities no longer teach.

As systems built on legacy code continue to operate, IT departments must make a decision whether to update them, and when. Or, perhaps they are not making a decision and hoping everything works out for the best.

In any case, it may be worthwhile to consider technology escrow for systems built on legacy code. With an uncertain environment, a copy of your developer’s source code held with a trusted third party, such as Iron Mountain, adds a safety net in case your developer is not available to support the application. Technology escrow can act as a safety net during transition planning or a disaster recovery strategy for those intending to stay with legacy systems. Conversely, if you own the code or developed it, do you have an independent benchmark of that code somewhere other than your IT department? Learn about the usefulness of an Intellectual Property Development Protection Account, or IPDPA.

More in Technology Escrow