Selected from IEEE Spectrum
Machine Heart Compilation
Edit: Egg sauce
Between 75% and 80% of companies want to move away from COBOL because they can't keep up with new developments like machine learning or cloud integration.
Recently, Sid Mohanram, senior vice president of software engineering at Verisk, a large data analytics and risk assessment multinational company, was responsible for the migration of corporate systems from the COBOL programming language.
Verisk is just one of many companies that do. Now, companies and governments are exploring alternatives to programming languages that run some of the world's most critical applications.
"Our goal is to get rid of the mainframe." Mohanram said.
The spread of COVID-19 has sounded the alarm for organizations writing core computer systems using the 60-year-old programming language COBOL, and in the United States, New Jersey, Wisconsin, Vermont, Iowa, Kansas, and even the federal government are facing a shortage of COBOL programmers, and some systems are not able to maintain good operations in the face of a historic spike in the unemployment benefit system.
However, the shortage of COBOL programmers is not the only problem. In the high-speed world of programming languages and software development, COBOL has become an obsolete (though still quite reliable) machine.
"We were slow to implement changes in COBOL, and people started looking for workarounds," Mohanram says, which has led to the accumulation of so-called "technical debt."
"The developer said: I need to make changes, but I'm too busy to make COBOL changes, so I won't touch the existing COBOL program, but I'll add three more steps beyond COBOL, including an Excel spreadsheet or something else, to apply the changes. So there are these very outdated COBOL programs and a bunch of other stuff as a workaround to get the end result."
One of the reasons there are still so many programs that use COBOL is that it is surprisingly stable. But today, flexibility is even more important for many applications.
"COBOL code is attack-proof because it almost never changes," said Mathew Lodge, CEO of Diffblue, a startup that automatically writes unit tests for Java and other updated programming languages. "But that's the old world, and the reality is the complete opposite – you have to change all the time to stay competitive."
IBM mainframes run most of the world's COBOL code and have an entire team dedicated to advancing the technology, so customers can continue to use the language. Barry Baker, IBM's vice president of Z product management, said Barry Baker, IBM's vice president of Z product management, "We've been investing in this, even if it's just to find people or to help them truly intuitively understand the flow of data across applications in terms of tool features and products."
Applications built with COBOL are often not well documented, baker says, and sometimes even entire modules of the original source code are lost. Meanwhile, the people who designed these apps have retired, and sometimes even passed away. In addition, testing COBOL programs can also be a problem, as many COBOL programs were written in the era before unit testing became widespread.
"Tests are most effective when they are written at the same time as code," Says Mohanram. He added that the best practice now is to write unit tests first, because unit tests describe the requirements and then write the actual functions to get the expected output for a given set of inputs. "Unit testing will force developers to write code that is easier to test."
However, IBM's Baker says unit testing has actually been available to developers for quite some time. "About 20 years ago, when I was a developer, I used test-driven development in my own IBM Z development."
Cyrus Montakab, founder of SoftwareMining, says testing can be more expensive and more difficult than translation, and Verisk is using its tools to translate COBOL code into modern programming languages. "We've been telling people to start translating now so you can test the last COBOL programmer before they leave."
There are also AI tools that support automated unit testing, which can speed up the process and save money, such as Lodge's Diffblue using reinforcement learning to automatically write unit tests.
"If you want to use the code in a modern software process, you not only need to translate the code, but you also have to come up with a set of unit tests to quickly find errors," said Lodge, whose company is helping large pension funds rewrite COBOL programs in Java. Use automated testing to ensure code quality while keeping up with the needs of the market.
Reuters estimates that 220 billion lines of COBOL code were still in production in 2015, running 43 percent of the world's banking systems and 95 percent of ATMs, including traffic lights, airlines, pension funds and payroll systems, which regularly run on COBOL.
Many companies are reluctant to touch a larger COBOL application as long as it still works. "It's always delayed, and the old IT director says it's not up to them," said Walter Sweat, chief technology officer at Astadia, the company that helped replace COBOL. "They don't want to take the risk and push it to the next generation, but at some point, someone has to deal with it."
Sweat says he sees exiting COBOL as a growing trend. Two years ago, only half of the prospects he interviewed wanted to migrate their systems to different programming languages. Now, 75% to 80% already want to get rid of COBOL. This is because COBOL programs cannot keep up with new developments such as machine learning or cloud integration.
For many traditional banks, with the explosion of mobile finance apps, this programming language could meet the challenges of the future, which allow consumers to do everything from basic banking to commodity trading on their phones. However, record profits across the industry illustrate a different story, suggesting that these traditional banks have been able to build their own mobile apps backed by services and data running in COBOL.
Baker said IBM believes coBOL used in enterprises is unlikely to disappear anytime soon, but translating critical applications into more flexible languages is easier than ever.
Reference link: https://spectrum.ieee.org/cobol-programming-shelf-life