Long-Enduring COBOL May Still Have a Shelf Life

Sid Mohanram, senior vice president of software engineering at Verisk, a huge data-analytics and risk-assessment multinational, is overseeing his company’s migration away from COBOL. He’s part of a trend as companies and governments are exploring other options than the programming language that runs some of the world’s most critical applications.

“The goal is to get out of the mainframe,” Mohanram said.

The COVID-19 pandemic has been a wakeup call for organizations running critical computer systems written in the 60-year-old programming language, COBOL. In the United States, New Jersey, Wisconsin, Vermont, Iowa, Kansas, and even the federal government have faced shortages of COBOL programmers to keep unemployment benefit systems running amid a historic spike in claims.

But a perceived shortage of COBOL programmers isn’t the only problem. COBOL has also become an old (though still quite reliable) clunker in the high-speed world of programming languages and software development.

“The speed by which we can implement changes in COBOL is slow, and people start building workarounds,” Mohanram said, creating a buildup of what he calls “technical debt.” “Developers say, ‘I need to make a change, but I’m too busy to make the COBOL changes, so I’m not going to touch the existing COBOL program, but I'll add three more steps outside of COBOL, with Excel spreadsheets or something else, to apply the changes.’ So now you have this COBOL program that's very dated, and a bunch of other things that are workarounds to get the final result.”

“We keep telling people to start the translation, so you can test it before the last COBOL person leaves the building.”
—Cyrus Montakab, SoftwareMining

One of the reasons there is still so much COBOL around is that it is remarkably stable. But flexibility is more important for many applications these days.

“COBOL code is bulletproof because it almost never changes,” said Mathew Lodge, CEO of Diffblue, a startup company that automates the writing of unit tests for Java and other, newer programming languages. “But that was the old world and today it is the complete reverse—you must change all the time to remain competitive.”

IBM, whose mainframes run the majority of the world’s COBOL code, has a whole team dedicated to advancing the technology, so clients can continue using the language.

“We've been investing, above and beyond, in just finding people to work on it, in tooling capabilities and offerings that help them actually visually understand the data flow across those applications,” said Barry Baker, IBM’s vice president of Z product management. Z is the brand name for IBM’s most advanced mainframe computers.

Baker says applications built in COBOL are often poorly documented—and occasionally even whole chunks of the original source code are missing. Meanwhile, the people that designed the applications are retired or sometimes dead.

In addition, testing COBOL programs can also be a problem because many COBOL programs were written at a time before unit testing was common.

“Testing is most effective when the tests are written at the same time as the code,” said Mohanram. He added that the best practice today is to write the unit test first, because the unit test describes the requirements and then code the actual function to get the expected output for a given set of inputs. “Unit tests will force the developer to write code that is easier to test.”

COBOL migration “gets postponed and postponed, and old IT directors say, ‘not in my time.’ ”
—Walter Sweat, Astadia

However, IBM’s Baker says unit testing has actually been available to developers for quite some time. “I was using test-driven development in my own development on IBM Z when I was a developer about 20 years ago,” he said.

Testing can be more costly and difficult than translation, said Cyrus Montakab, founder of SoftwareMining, whose tools to translate COBOL code into modern programming languages are being used by Verisk. “We keep telling people to start the translation so you can test it before the last COBOL person leaves the building,” he said.

There are now AI-enabled tools to automate the writing of unit tests, speeding up the process and saving money. Lodge’s Diffblue uses reinforcement learning to write unit tests automatically.

“You don’t just have to translate the code, you also have to come up with a set of unit tests to find bugs quickly if you want to use that code in a modern software process,” said Lodge, whose company is helping a large pension fund rewrite its COBOL programs in Java. He said that using automated tests ensures code quality while keeping up with the demands of the market.

Reuters estimated in 2015 that there were 220 billion lines of COBOL code still in production running 43 percent of the world’s banking systems and 95 percent of its automated teller machines. Traffic lights, airlines, pension funds, and payroll systems all regularly run on COBOL.

Many companies have been reluctant to touch larger COBOL applications as long as they are working. “It gets postponed and postponed, and old IT directors say, ‘not in my time,’ ” said Walter Sweat, CTO at Astadia, a company that helps companies get out of COBOL. “They don’t want to risk it and push it to the next generation, but someone will have to deal with it at some stage.”

Sweat says he sees getting out of COBOL as an increasing trend. Two years ago, only half of the potential clients he spoke to wanted to move their systems to a different programming language. Now, he says 75 to 80 percent want to get away from COBOL.

That is due in part to the relative difficulty COBOL programs have keeping up with new developments, such as machine learning or cloud integration.

For many traditional banks, this programming language could potentially create future challenges with the explosion of mobile financial applications that allow consumers to do everything from basic banking to commodities trading on their phones. However, record profits across the industry tell a different story, indicating those traditional banks have been able to stand up their own mobile apps backed by services and data running in COBOL.

Baker says IBM advises businesses that COBOL isn’t likely to disappear anytime soon—but translating critical applications into more flexible languages is getting easier all the time.