Why COBOL will never die

There are an estimated 240 billion lines of COBOL out there, and they're the backbone of your financial life — 95% of the time when you swipe your bank card, there's COBOL involved, and every night when the work-day is over, the massive mainframe farms of big banks leap into action, using COBOL to balance the day's books.

Why is COBOL — which debuted in 1969 — still so crucial to everyday life? The online finance magazine Wealthsimple asked me to write about that, so I talked to tons of COBOL folks, including some programmers who wrote bank routines in the 1980s that are still being used today — they're long retired, in their 70s, and their banks still call them up to ask them to maintain the stuff.

There are lots of reasons COBOL's still around, but one that's intriguing is that three-decade-old code is stable as hell. You have code in production that long, it's been debugged within an inch of its life; and they've had decades to tweak the compilers — which turn the COBOL into instructions for the machine — for massive efficiency.

This turns the new-new-thing hype of Silicon Valley on its head, of course. It's a sector obsessed with the hottest, latest thing — but as any programmer can tell you, the hottest, latest thing that just got shipped at 2 am is gonna be a rickety kluge of buggy code. That old COBOL, though? In service since the days of early MTV? It's tough as old boots.

Remember the hype cycle this spring about how unemployment systems in various US states — pounded with new demand by COVID unemployment — couldn't keep up with demand? The culprit, state officials said, was COBOL: Those antique systems just couldn't keep up!

That was nonsense. The stuff that was breaking was all the newer code:

This idea — that older code can not only be good, but in crucial ways superior to newer code — is at odds with a lot of Silicon Valley myth making. Venture capital-backed startups usually tout the shiny and novel. Founders do not prance around boasting about how old their codebase is. Quite the opposite: They brag about their code being cutting-edge, pounded out in all-night sessions by bleary-eyed genius 21-year-olds. But as nearly every programmer will tell you, the newer and more recently written the software, the more likely it is to be a hot mess of bugs.

A good example of this could be witnessed during the pandemic. In the early days of Covid-19, businesses shut down en masse. Laid-off employees swarmed online to apply for unemployment benefits, and the websites for many state governments crashed under the load. In New Jersey, the governor told the press that their COBOL systems desperately needed help to deal with the new demands. "Literally, we have systems that are 40-plus-years-old," he noted.

But technologists who were working behind the scenes to fix the problems knew that the number-crunching COBOL wasn't the problem. That old stuff was working fine. No, it was the newer stuff that had crashed — the programs powering the website itself.

"The thing that went bananas was this web application in between the mainframe and the outside world. That was the thing that sort of fell apart," says Marianne Bellotti, a programmer and writer who worked for years on government systems, and who observed New Jersey's system. But it's too embarrassing, as the historian Hicks points out, to admit that "oh, our web systems broke down."

Bellotti's seen the same thing happen with other government agencies, like the IRS. She was called in once to help with an IRS web app that wasn't working. When they investigated, they found that, indeed, the problem was in newer programs, "this chunk of poorly written Java code". The mainframe running COBOL, in contrast, was racing along like a Ferrari.

"The mainframes," she says, "were responding within milliseconds."

That photo is of Grace Hopper, holding a rad-looking COBOL manual. Hopper is often referred to as the "mother of COBOL", but this is not quite true. It's true that she deeply influenced the development of COBOL, particularly by creating the precursor language FLOW-MATIC (possibly the most metal name ever for computer language).

But in terms of actually getting the work done on creating, promoting and evolving COBOL, there were many other key folks, including Mary Hawes — who got the ball rolling — and Jean Sammet, a main architect for COBOL; I mention them in my piece, but Mar Hicks dives deeper into their work in a superb piece on COBOL in the latest issue of Logic magazine.