Early in the 2020 coronavirus pandemic, the New Jersey state government had a very specific IT staffing need—and it got a lot more publicity than hiring moves usually get. The recently passed CARES Act had added $600 to weekly unemployment payments nationwide, but New Jersey’s archaic unemployment software, written in COBOL, couldn’t incorporate the extra money without reprogramming, and there was nobody on staff capable of doing the job.
The incident was a very public glimpse at a dirty little secret within IT: There are billions of lines of code written in COBOL still running mission critical applications, but the great wave of COBOL-trained programmers who wrote all that code are aging out of the workforce. That story isn’t new—we wrote about it eight years ago, and eleven years before that.
But the COBOL era has persisted to present day, and many legacy systems have muddled on, only half understood by the companies that rely on them, after the expensive “big bang” projects to replace them failed. And now many experts are thinking of new ways to approach the problem COBOL applications present—and to develop the skills necessary to work with it.
COBOL is easier (and harder) than you think
One of the problems with conversation around the COBOL skills gap is that we often assume the existence of a distinct breed of person known as a “COBOL programmer,” as if COBOL itself is something so different from the rest of the programming world that it needs its own specialized caste. But that simply isn’t the case.
“COBOL is a red herring in this whole debate,” says Mark Cresswell, CEO of LzLabs. “It’s just a syntax for expressing business rules. Most programmers are polyglots. You might have a specialization or you might be better in one language or another, but you’re not going to say to yourself, ‘Well, I’m not going to do C++ because I’m a Java programmer.’ COBOL, as a language, is no different from any other language, really. It has its own idiosyncrasies but so do all languages.”
Keep in mind that COBOL (which was created in the 1950s) was specifically designed as a way for non-specialists to program the computers that were starting to enter the business world. “The BOL is business-oriented language,” says Emad Georgy, CTO of Georgy Technology Leadership. “It’s meant to be easy to read and easy to understand. I think there’s this huge fear around it because it does run some fairly mission critical systems, but actually, as a programmer, it’s very easy to learn.”
COBOL isn’t built around object-oriented programming and lacks inheritance features, so those who have cut their teeth on modern systems will actually have an easier time picking it up than an old COBOL hand would trying to learn Java or C++. (Although “modern” object-oriented versions of COBOL do exist, they aren’t used in the legacy systems where you’ll actually encounter production COBOL in the wild.)
In truth, when we talk about a “COBOL skills shortage,” that’s usually shorthand for something more complicated. You could, for instance, download GnuCOBOL and start tinkering with code that will run on a familiar Linux machine, but that wouldn’t prepare you for the experience of working with production COBOL code in its native habitat.
“To learn COBOL is easy, but its applications require rare expertise with legacy technology, such as IBM’s IMS and CICS database systems,” says Michael Yurushkin, CTO and founder of BroutonLab. “The key challenge is not learning the language, but having the expertise in technology that is many decades old.”
LzLabs’s Cresswell emphasizes that the modern set of tools developers have come to rely on over the past decade simply don’t apply to mainframe environments. “If I want to compile and test a program, I’m not pressing the little green arrow on the toolbar,” he says. “I’m running a thing called a batch job that does a compile and a link. When it comes to setting up a test environment, I can’t just spin up a container on my workstation to test my changes. I have to speak to systems administrators to configure partitions with arcane subsystems and configurations. All of this elongates the development cycle and is so idiosyncratic that it’s very difficult for somebody that is used to developing at internet speed on cloud platforms to get their heads around it.”
And if you’re dealing with a long-running, mission critical application, untangling the program logic may end up being your primary challenge. “All these systems have been crafted over decades,” says Ben Stevens, lead engineer and solution architect at Art+Logic, who worked for years at government agencies that relied on COBOL. “If you don’t know those ins and outs, knowing the language is only going to do so much. It ends up becoming a reverse engineering project where you’re acting as an archaeologist. Even if you know the language, it’s like you’re reading these ancient texts without any context: Okay, I can translate this word by word, but what does it mean?”