I’ve been way too busy to address the story when it first broke, but that’s how the burrito’s been rolling around here lately. Briefly, here’s the sequence of the story which made my blood boil:

• COVID-19 pandemic hits
• World recession (if not depression) hits
• An unprecedented number of citizens in US file for unemployment
• US government issues economic stimulus checks so the economy doesn’t go boom
• IRS, banks, and other institutions report a crisis: they can’t help people fast enough because their machines are using… COBOL!

This triggered an avalanche of ignorant technology story headlines the likes of which haven’t been seen since Y2K.

“Wanted urgently: People who know a half century-old computer language so states can process unemployment claims!” screams CNN.

“Government systems written in the old COBOL computer language are blocking us from our cash!” gurgles ZDNet, the FOX News of tech media.

“Unemployment checks are being held up by a coding language almost nobody knows!” valley-girls The Verge.

“An ancient programming language is suddenly in demand thanks to the pandemic!” derps Salon.

It’s been going on like this for weeks. The drooling stupidity dripping over these stories is inexcusable in the year 2020. The media, let us never forget, is chock full of stubbornly anti-intellectual reporters who flat out refuse to learn because what’s the money in reporting an accurate story?

So, for those of you just joining us (because everybody else lies to you), allow the World’s Oldest Blogging Hacker to explain this mess…

Myth #1: There is a shortage of COBOL programmers

One need only visit the comments section under this story breaking on Slashdot to see what the real story is.

> “There are still lots of pros that specialize in COBOL [quora.com]. You just need to pay them what they’re worth instead of asking for volunteers. Even if some 66-year-old wants to come out of retirement and do it, you should still pay them. This is a BS story, from the likes of “it’s old, so let’s make fun of it.” If anyone on this planet has the finances to rewrite their software, it’s banks and financial institutions. If they’re not rewriting it, then you can bet they’ve done a cost benefit analysis on it.”

Yeah, there’s no shortage of COBOL programmers. There is instead a shortage of government and business offices who are willing to _PAY_ the COBOL programmers. Here’s a bunch of them. They’re not even all that expensive, some as cheap as $15 to $20 per hour, burger flipping wages. Here’s even more, all starving out of work because they signed up for Guru instead of UpWork. And people ask me, “Pete, you can code, why don’t you do that for work?”

Here’s a Quora thread asking for COBOL programmers back in 2017, a few respond and a few more say they know several.

This is a completely invisible crisis. There is no shortage of COBOL programmers, never has been. There is a shortage of “volunteer” programmers, like there’s a shortage of every other kind of volunteer in a skilled, unrespected trade. I, myself, know enough COBOL to at least dope it out. I also know that working for free for an institution that is clearly able to pay is detrimental to my eating lifestyle.

Myth #2: “COBOL programmers” are a thing

All of us computer geeks are still screaming rebuttal to this myth, as we have for at least forty years and it likely will never penetrate. There is no such thing as a “COBOL programmer” or a “BASIC programmer” or a “C++ programmer” or a “Java programmer.”

There are only PROGRAMMERS.

WHAT LANGUAGE DOES NOT MATTER!

None! The important thing in the coding arts is that you understand the fundamental mechanics of computer logic, logic flow, algorithms, frameworks, development methods, debugging, data structures, stacks, pointers… These concepts are present in every possible scenario where you’re making computers do things.

Look, here’s “Hello World” in every programming language, a page on the web now older than most of you reading. It’s a canonical exercise where we print a line of text to output, the most basic unit of making a computer do something. All languages have this, plus more or less a standard set of common operations, functions, input / output methods. Either the language has the feature natively or you import it with a library. The differences don’t show up until you get into matters pertaining to things like “where will this program run?”

I’m simplifying some of the above, of course. Some smart asses go out of their way to code esoteric joke languages. Ignore them, they’re trolls.

The point is that no programmer, none at all, goes through life knowing only one programming language. Instead, programmers pick up whatever tool they need for the task at hand. Some jobs want a hacksaw and some jobs want a hammer. Give me any ten random developers with a few years under their belt and I will teach them any language you can name in a week, and that’s including the time it takes to learn the language myself.

Which is why, after the “crisis” leg of the story broke and simmered for a few weeks, IBM and the Linux Foundation have had no trouble at all “finding” and training (emphasis on) COBOL programmers. Aha, here are the missing COBOL programmers! They were hiding behind the couch, those playful scamps.

Myth #3: The problem is COBOL

A long time back for another tech publication I got in social media trouble for controversially asking “Why do we want COBOL to die?” Because that line of inquiry also never goes away.

• “When will the mainframe and COBOL die?” – Quora
• “Banks should let ancient programming language COBOL die” – TheNextWeb
• “COBOL Turns 60, Still Won’t Die” – I, Programmer

COBOL: “Geez, guys, I’m right here!”

Every hacker wants COBOL to die, as far as I hear it, and yet it does not. Why?

Well see, there’s the perfect, ideal world the hacker lives in, and then there’s the grubby, rusty, industrial world of the business and government sector. Code must also live here, too, because that’s how code makes money. In talking about the chasm between the two worlds and why they don’t understand each other, we have to start with the very first computer bug and end up in the guts of the mainframes that are processing your credit card payments this very second.

COBOL does exactly what it was designed to do… at the time. This takes a bit of explaining, in two parts.

Part 1 – Grace Hopper

Now a poster candidate for women in STEM, but also blamed for one of the most hated programming languages on the planet.

Conventional wisdom asserts that Grace Hopper was the grandmother of COBOL, but actually, she was more of the midwife, having served as a technical consultant to the committee that designed COBOL. Grace Hopper is such a legendary figure, celebrated today as the hacker’s own “Rosie the Riveter,” that her legend is in the mythology phase.

For instance, yes, that’s her moth in the Smithsonian, but the word “bug” as in “mechanical malfunction” was well in use before Hopper’s time, and there’s no evidence that anybody referred to the moth-ectomy as “debugging.”

Hopper’s story also represents an aspect now lost to history. Today, it’s common to ask “Where are all the women in computing?” But up until the 1960s, computers were a female-dominated field! At the time, computers only crunched numbers and were bulky, awkward things that required lots of hands-on operation. This was seen at the time as “women’s work,” by anology with secretaries, typewriters, copiers, and other brute-force tech. That’s a history lesson for another time. The point is that at the time, programming languages were designed to be dumbed down. Way, way, waaaaay down.

In any case, Hopper was an amazing mathematician and computer scientist, as well as having an accomplished military career and further work in the private sector with DEC. But when a Department of Defense committee designs a programming language, “amazing” is the last thing on their minds.

They want it simple enough that a monkey could understand it (government and business sector standards being what they are), so robust it could survive the apocalypse (and what a test for that standard COVID-19 is!), and as feature-poor as possible, so that fancy tricks don’t get in the way of its grubby primary job. At the time, managers had to train new hires because there was no Dice.com. Managers had to understand this technical stuff. Managers with cheese for brains. Programming languages at the time, BASIC / PASCAL / FORTRAN / etc., had to be drool-proof first with power a distant consideration.

COBOL was designed to fit that niche. Spoilers: it’s going to keep fitting it forever. Even COBOL programmers know it, which is why we have sites like COBOL Zombies.

Part 2 – The environment where COBOL was deployed…

You’re all in for a stroke of luck here, because your Present Author just so happened to work in the financial sector, in the operations headquarters of a multinational corporation whose name, were I to utter it, would no doubt draw hisses of contempt.

Everything I say here can be applied to the government sector, and other business quadrants like the insurance sector, stock markets, the legal system, etc. Any computer system deployed to just mindlessly crunch numbers on a huge scale, but do so reliably and without fail forever, applies. Yes, even the IRS.

And I’m here to tell you the fact that legacy systems stick like glue in this industry.

Sure, they still use updated stuff too. They’ll order ten units of this week’s shiny new computer, and then the engineers will set them up and plug them into the system right next to a Windows NT system… which is networked to an Intel 486 running OS/2 Warp… which is talking to some ancient beige horror with a monochrome Hercules monitor on a box with a turbo button and a key lock… which is mounted as the front end to a VAX mainframe… and so on down the history of computing museum, all of it working together in one big chugging pile.

Imagine Rube Goldberg as a hoarder who works in IT. Nothing is ever allowed to be polished. Everything is duct-tape, ad-hoc, crufted-in, last-minute, jerry-rigged and caddywumpus. If it ran the first time, we are never going to unplug it again.

They’ll add new stuff all the time. But throw something away??? When it still lights up when we turn it on? When we have to justify every paper clip on a documented expense report? Are you crazy?

Banking is the purest Capitalistic business; it pretty much has to be. So when anything gets done the first time, it’s made from scratch with whatever parts they had at hand at the time. Once it’s plugged in and you know what it does, you will get no second chance to build it better. It’s already become part of the system now. Since the banking industry works against both negligence and fraud by having your name and ID# attached to everything you touch, nobody wants to be The Person Who Broke It, because when things break, billions of dollars disappear and all anybody cares about is “who’s to blame?”

So yes, theoretically, you could test out a new replacement part before going live… except there is no test version of the whole big system, no comparable simulation of it, because all of it was built from scratch with whatever parts they had at hand at the time. Field service contracts last for generations in this industry. Everything gets fixed with a hot patch of the first crufty solution that came to mind for whoever was stuck fixing it. Code review, ha ha, what’s that?

While we’re at it, can you guess what the real problem is? The real problem is not COBOL. The real problem is the “design” methodologies of the environments where COBOL is deployed. Did you notice that at no point in the rant above did I mention such a beast as “documentation”?

Ha ha ha, documentation, what’s that! How do you justify to a manager that you need to “document” something on company time? Look, the manager pulls out this yellow, dusty receipt from when the company bought into COBOL. It says right here: “Self documenting!”

Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps. We kick out dozens of new video games every year, but apparently the last payroll printing program was written in 1965 and nobody ever wants to do one again.

Myth #4: Want A Job? Learn COBOL!

Ever since Y2K (which was pinned entirely too much on COBOL), the tech industry has been indignantly waiting for the financial sector to wake up and smell the modern coffee. But I’ve just pointed out why that’s not happening. Sure, you can be the pioneer who brings the light of Ruby On Rails to the dusty banking world, but when you do, the machine your code is running on will just be cabled over to the same old machine running COBOL.

There’s a layer of COBOL under just about every part of our infrastructure. It is never going away for the reasons I just documented above. I mean, not unless Tyler Durden comes along and blows all the banks up so they have to start over and build it all right this time.

Even then, chances are they wouldn’t do it right the second time either. Can you imagine the headlines 60 years from now? “Arcane programming language Ruby on Rails prevents us from repelling the alien invasion!”

So yes, you will have a job for life every bit as prosperous as a job scooping ice cream for Tasty Freeze, if you learn COBOL. If you do, be prepared for a lifetime of struggling to patch ancient, hot, iron boxes which haven’t been opened since the Eisenhower administration, desperately scrabbling to figure things out under a crushing deadline, while an angry boss stands over your shoulder waiting to fire you at the first fumble.

Billions to trillions of dollars ride on these systems, I assure you, literally every problem is solved by assassinating a scapegoat.

Gee, I wonder why on Earth they can’t find any volunteers???