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?”
Developing COBOL skills within
So imagine your organization has a mission critical COBOL codebase. How can you make sure you have access to the skills you need—in terms of programming and mainframe environments, as well as the underlying business logic—to keep the system up and running, at least in the near term? One strategy is to work on developing skills internally. That doesn’t mean hiring fresh COBOL programmers right out of college (since those don’t exist). It also doesn’t necessarily mean retaining the graybeards full-time when they’d rather retire.
“My goal for my team would be not to teach them COBOL. It would be to teach them my system,” says Georgy. “The context is key. You want them to learn just enough COBOL. You probably won’t be doing any new projects in COBOL, so you have to be judicious about the level of investment.”
To that end, you would pair up interested internal developers with whatever resources you have on hand, with a laser focus on your particular business needs. This may involve having older developers who have worked on the application in question—maybe still on staff, maybe brought back in as contractors—mentoring younger ones.
“I like to have very specific use cases or problems that we’re trying to solve with the training,” says Georgy. “Like, ‘Look, you three, you’re going to work with this retired person who’s going to come in and spend a few hours every week. Our goal by the end of the month is to resolve this bug.’”
Developers will need to pursue a more general education in COBOL and mainframe programming as well to supplement what they learn about their own systems. IBM has an obvious interest in keeping a critical mass of COBOL programmers in the market, and offers a variety of educational resources, like free COBOL programming courses and mainframe programming certification badges. Taking these courses will occupy staff time, but you may find the investment worth it.
“Our clients also need to remember that maintaining mission critical applications that have been optimized over the past several decades does require upkeep,” says Barry Baker, vice president of software at IBM Z. “While it can be easy to cut corners or think you can squeak by without investing in talent, that is simply a recipe for disaster.”
Don’t be afraid to ask for help
Nevertheless, you may find yourself in a situation where you simply don’t have the internal resources to deal with your COBOL crisis. In those cases, you may want to turn to an outside consultancy that specializes in working with COBOL systems. Pravin Vazirani is vice president of operations at Chetu, a company that does just that, and the situations where they’re brought in to help are often fairly dire.
“There have been many cases where the core developer of the legacy platform is no longer with the company,” Vazirani says. “And the maintenance of the system is being done by a developer who has limited knowledge of the system but just enough expertise to successfully run the COBOL apps. This is usually in places that are running legacy platforms with little to no proper documentation.”
Vazirani believes that many organizations—especially smaller ones—will save in the long run by using specialist third-party companies like his. “COBOL development expertise is not as common outside of custom development firms, so in many ways, hiring an efficient, low-cost development firm can be more cost-effective for companies rather than hiring and cultivating in-house talent,” he says. “And many companies may be looking to transition away from their COBOL apps in the near or distant future, so more emphasis would be placed on bringing on in-house talent to address the future needs of the company, while a third-party handles the current system.”