I wrote a story about it for our website, and it climbed to the top of our chart. But it was more than that: Major news outlets were covering it. Public relations firms were sending me links to my own story in email pitches. It was everywhere, and we all gleefully dunked on COBOL because — well, this is technology we’re talking about. How could we still be running such important systems on such old code?
Never mind that spokespeople for the state later gently suggested that they did, in fact, have enough programmers to run the system — maybe, sort of, perhaps implying that the governor was mistaken.
That’s not the point. The point is this: Too many people were itching to attack COBOL because it’s old. And not only is that itch wrong, it’s also a far-too-pervasive attitude that distracts from more urgent needs.
William Malik, vice president of infrastructure strategies at Trend Micro and a longtime veteran of COBOL and enterprise technology, puts it this way: “[New Jersey is] probably running a machine that’s 10 to 15 years old, for pretty much the same reason that I drive a 2006 Audi: It gets me where I need to go, I don’t need to go any faster, it’s perfectly safe, I keep it maintained and I know how to drive it.”
What likely caused the problems in New Jersey, Malik argues, was unrelated to programming languages, but rather was about processing power or memory.
In other words, this was about supply and demand. The system was built to handle a normal number of unemployment claims, but it existed in a moment that was anything but normal.
Before we go any further, let’s lay down some basic facts. COBOL was developed around 1960 as an early programming language that dealt in abstractions. That is, it allowed developers to give commands to computers in plain language. It’s oriented toward business functions and still runs many of the world’s most important financial systems, including the IRS and banking giants. There are hundreds of billions of active lines of it, and that number is growing over time, not shrinking.
For this article, I sought out the counsel of several experts in addition to Malik. I talked with Marianne Bellotti, a U.S. Digital Service alumna who now works for the tech firm Rebellion Defense; Phase Change Software COO Steve Brothers; and Pennsylvania CISO Erik Avakian. They had much to share, and I wish I could put it all down here.
In lieu of a transcript, here are some things they agree on: Despite its age, COBOL is still the right choice for some tasks.
“It was designed to do batch processing of data, particularly calculation-based processing of data,” Bellotti said. “So if you have a problem that looks like that, there are many other technologies you could use that would serve it well, but you could also choose COBOL, you could also use a mainframe, or you could just use the mainframe and Python, what have you.”
Another agreement: COBOL is not much of a security concern.
“COBOL doesn’t present any security problems because it doesn’t really talk to any resources,” Malik said. “It just says ‘read’ or ‘write.’”
If there are security concerns about COBOL applications, they have more to do with IT architecture and workforce than with the fact that they’re written in COBOL.
“The challenges associated with older technologies and software, like COBOL, can include applying security updates and modern approaches to data encryption and authentication, such as multi-factor authentication,” Avakian wrote in an email. “Additionally, IT staff skilled in these technologies and software have become increasingly scarce in the workforce, making them riskier to maintain and update.”
And yes, let’s talk about workforce. Every year or two the Internet cycles through headlines about surveys talking about how such-and-such percentage of the people who know COBOL are approaching retirement age. The problem, as Bellotti points out, is that the average age of COBOL programmers actually doesn’t change that much over time — in 2006, a survey from Computerworld found that the average age of COBOL programmers was 45 to 55, and in 2020 a survey from Micro Focus found that the average age of COBOL programmers was 50. Gartner estimates that the total number of COBOL programmers is decreasing each year, and yet companies like Micro Focus and IBM are training thousands annually on the language.
There is a serious issue with retiring talent, but again, it’s not unique to COBOL. The issue is institutional knowledge — when the people who wrote an application 20 years ago leave, the remaining people often don’t know the application with anything close to the same intimacy. And since the time they first wrote the program, often it has metastasized — grown new functions, filled new use cases, entered new agencies. So it’s a lot bigger and more complex, and the people who understood it all just walked out the door.
“The developer that understands a programming language, if they’re dealing with a very small amount of code, they can fix the problem and they can fix it pretty easily,” said Brothers, whose firm works on this exact problem. “The problem is when you’re dealing with millions of lines of code and nobody even knows where to start looking.”
So what does it actually cost us to focus too much on COBOL? Largely, time and resources that could have been better spent elsewhere. Here’s a thought experiment from Malik: Say an IT agency takes a COBOL app and re-creates the whole thing in another language.
“If you take a piece of working code and you rewrite it in another language, you now have to retest the whole smash,” he said. “And at the end of the day, what you now have is a new program that does exactly the same thing as the old program, and you sit down and you say, ‘Why did I spend my money on that project? Didn’t I have any users that wanted a new interface? Didn’t I have any business units that were pounding on the door for a new application?’”
Meanwhile, we have cybersecurity breaches happening all across the country at every level of government, shutting down public services, costing money and handing intelligence to foreign governments. And citizens still have a hard time navigating benefit applications. And manual entry still contributes to human error in much government work.
So before inventorying your COBOL catalog — have you thought about security flaws in your supply chain? Your middleware? How’s that patching program coming along? Are you running unsupported technology?
And yeah, there are times when it makes sense to move something off COBOL. But if you’re going to do that, it’s probably better to think holistically, along the lines of transforming architecture. As Bellotti puts it, the question you might want to ask yourself is: If you were to re-do it today, how would you do it?
“I really heavily emphasize user utility and value add with modernization projects,” she said. “We don’t just move off technology because it happens to be old; we move off technology because there is a better tool to do the job we need done.”
Just because it’s old doesn’t mean it’s bad — ain’t that the truth.
