Necessity may be the mother of invention, but a crisis can reveal the danger of not modernizing. Faced with a flood of new unemployment claims stemming from the economic fallout of COVID-19, New Jersey Governor Phil Murphy put out a call for COBOL programmers. The state needed to scale up its unemployment insurance system to accommodate the surge of applicants. The problem was the state did not have enough IT personnel versed in some of the underlying code that is intrinsic to its system.
[The Legacy Code Rocks! podcast hosted a follow-up to this story:
This issue may sound like a recurring headache for organizations that likewise have not made headway updating legacy systems even in the era of digital transformation, DevOps, and agile development. Scrambling to find former programmers under the pressure of a crisis can be a dicey prospect. Experts from Modern Systems and SaltStack shared insight on what is at stake if old code lapses into technical debt and steps needed to address the situation.
A potential fix for such a situation could include finding programmers who can try to rearchitect applications in COBOL with the intent of parallelizing the workload to multiple to servers, says Brandon Edenfield, managing director of app modernization with Modern Systems. “That’s no easy task.” The problem is not just the age of the language -- many schools no longer teach COBOL, he says. “That’s not where the market’s going. I am a COBOL programmer; I love COBOL, but that day is passed,” Edenfield says. “Modern environments have left it in the dust.”
Moving on from old code can be a daunting task, says Thomas Hatch, CTO and co-founder of SaltStack. In years prior, he worked with the intelligence community as agencies tried multiple times to modernize to no avail. “They weren’t able to find anyone who could even figure out how the old code worked,” Hatch says. “It’s not always as easy as it seems.”
Edenfield and Hatch offer these considerations organizations should weigh if legacy code is still woven into their systems.
- Take Inventory--Executive leadership should be aware of what makes up their environment. This includes applications, databases, and platforms.
- Understand Resources--Assess the languages and data structure being used and the number of people in the shop who can handle the systems.
- Explore Connections--Figure out the touchpoints of the legacy systems and whether there are peripheral systems written around them that could be affected by changes.
- Realize Liabilities--Analyze code that no one on staff can maintain and potential repercussions of lack of coverage. Identify ways to isolate that impact.
- Stagger Changes--Break out what applications need to be modernized are and try to address them in blocks or stages rather than attempt a systemwide overhaul in one move.
- Routine Cleanup--Organizations should conduct a “spring cleaning” process on a regular basis assessing dated code and systems for potential replacement.
With a history that stretches back three generations, COBOL was developed for a different breed of compute, Edenfield says. “These were massive machines that did certain things like number crunching,” he says. “It wasn’t fancy.” COBOL was designed to move across multiple machines and frankly to be readable, Edenfield says. “People could learn it quickly and it was easier than an assembly language where you are programming in very cryptic commands.”
As new compute demands emerged, programming languages evolved, Edenfield says. Agile development and other modern processes can be more efficient and fundamentally different from how COBOL and other early programming languages were handled. Despite such advances, it is a challenge to escape those legacy roots. “Because COBOL was so prevalent, they can’t get out of it,” he says. “There’s so much of it. It’s running all the backroom, payment processing for all your major financial institutions; all your big companies have it.”
It was common for organizations to constantly build up COBOL-based systems for decades, Edenfield says, with the programmers retiring or moving on. “Pretty soon, the people who wrote the systems aren’t there anymore,” he says. Over time, documentation of what was done with the code tended to become lax, he says, which meant institutional knowledge began to disappear.
There are cautionary lessons the private sector can learn from the struggles public entities face with legacy tech. “New Jersey is lucky they’re a government,” Edenfield says. “You can’t go somewhere else and get these [unemployment] payments processed.” If a commercial business found itself unable to scale up with a surge in demand, their more modern rivals who can adapt could snatch up their customers, he says.
Switching to newer software as commercial organizations might is not always viable for public entities, Hatch says. Sometimes the systems a government agencies needs are highly specific and cannot be reimplemented with other customers, limiting options. “There is a lack of overall motivation, particularly from a financial perspective, to write commercial solutions that allow you to recreate these systems,” he says. This leads to a diminished portability for the software and protracted reliance on the original code.
Even after organizations make moves to modernize, the process will eventually need to be repeated. Code tends to move through cycles of popularity, Hatch says, with COBOL and other legacy languages such as Fortran seeing their heyday in earlier decades. Banks, insurers, and large media outlets may still run software in the background that dates back to the 1960s and 1970s, he says. Issues now being seen with COBOL might one day be said about current, mainstream languages. “Imagine a world where you can’t find a Java developer,” Hatch says. “We’re probably going to have that world in 20 to 30 years.”
For more content on modernization, follow up with these stories: