I work with Medicaid claims data, and at least in my state (MO), most of it is stored and shipped as COBOL aggregated data.
4 Likes
True, the first work was done in 1959 – but it wasn’t standardized until 1969, and since the whole point was to have a common language with standards across multiple styles of machines, I count the release as 1969! Those ten years of careful work are precisely why COBOL was so well designed for its task, really.
I’m being pedantic, though; I think many more people would agree with you and 1959
8 Likes
A little pedantic perhaps, but isn’t Medicaid insurance?
ETA: You’re right, of course. Government systems, at least in North America, have a considerable amount of COBOL that needs tending to.
2 Likes
6 Likes
Disappointed that the phrase “Lords of COBOL” appears nowhere in this article
7 Likes
I’d add experience in the government or military. A lot of critical legacy systems chugging along in those sectors, too.
ETA: I see you mentioned that in the interim.
3 Likes
Agreed, as I mentioned in my edit to my reply to @MrShiv.
I’d edit the initial post but we’ve got a conversation going on it now so I’ll just leave it be. 
ETA: Lol, I missed your edit while replying.
3 Likes
Yup. At that time insurance companies were hiring a lot of grads to do COBOL.
2 Likes
I learned cobol in HS I really really wish they had taught C instead or did another year of basic instead. This was in 92/93. In my university Computer Science program there was a single elective for cobol (I took it to get an easy A and HS never bothered with any jcl or similar). Professionally I’ve never touched cobol and don’t really have a desire to, but there’s bits in the language that I sure wish were ported over to more modern languages or even to html. Like the way you can specify input parameters and out put parameters format by individual character position.
The main problem with cobol and the only reason to really replace it? replacing the hardware that runs it and replacing the humans that maintain is increasingly difficult. Mainframes seem to be an obsolete technology and I don’t know of projects to virtualize them on modern hardware (though there must be some? but will that be full of bugs?).
Reminiscent of psychohistorians of Asimov’s Foundation series, keeping and tending the corpus of their work over the course of centuries. Will COBOL survive a century??
3 Likes
Perhaps add to your article?
There’s an argument to be made about complexity as well. Older systems are slow, but far less complex. Fewer figurative moving parts.
Some great discussions about why not everyone should move their Monolith to Microservices:
1 Like
ADD TWO TO TWO GIVING FOUR.
2 Likes
I actually found when I started taking COBOL in college that it was difficult to understand and work with. All of my classes had been in C/C++ until that point.
Thinking in C programming mode will make life hard in COBOL. You have to think like a non-technical business person. It’s like going sane in a crazy world.
Once I had that lightbulb moment (after about a week), COBOL was cake. It was a wild thing, a singular moment almost where COBOL went from hard to easy.
3 Likes
Alternatively,
compute ls2 + ls2 = ls4.
It’s still one line whichever way you do it.
Other languages require math to be done too.
I mean… there are millions and millions of lines of code. It’s complex. And it’s been tweaked and modified over the decades by numerous uncoordinated efforts. I cannot believe this legacy code is a wonder to behold. The “simplicity” (crudeness) of Cobol means you’re writing much more code to accomplish the same result as that of an advanced language; the “advantage” of this is not immediately obvious.
The only thing going for this legacy code is: it has worked in the past and it is working now.
So how’s that different from modern software development? Focus on creating software that is valuable to the customer is at the core of any agile and lean methodology.
Of course there are shitty developers out there, but COBOL did not magically protect you from being a shitty developer.
So how’s that special in any way? That’s what programmers do when they write enterprise apps.
That’s probably because apart from to automated tests and sticking to the simplest thing that actually works, abstraction is the most powerful concept for dealing with complexity: the moment you introduce duplication in a system is the moment you make it an uphill battle when you need to fix or change the software later.
I would say this is a fundamental misunderstanding of abstraction, and of modern software development.
Like we didn’t learn anything since the 70ies but forgot half of all the good things along the way.
I have ported my share of systems written in Cobol (and Fortran, PL/1) from the 70ies to “modern” languages, because that was actually cheaper than understanding and cleaning up that mess and then add new features on top. In the most extreme case we ended up with around 10% of the lines of code, including automated tests. Of course we had ways to harden the systems before they went live, and we never had a major problem cropping up.
This. And everyone is forgetting about all the shitshows that went down when that code was fresh and buggy.
Indeed, COBOL (much like ABAP), makes simple things simple, even for the layperson, but it also makes a lot of things unnecessarily hard.
The people I know who still code in COBOL do so because there is some existing COBOL code that needs to be updated, and not because it is their language of choice.
Isn’t that strange that there should be a need for such an exceptional language to evolve at all? 
3 Likes
Not in the least. As hardware and operating system software advance so must programming languages to take advantage of those advances. Otherwise they fade away and don’t get used anymore.
COBOL may never die, but the jobs sure did.
I was a COBOL programmer from 1983 to 2000. One of the best. The kind that called IBM and Realia and MicroFocus and showed them where to fix their mistakes and add features.
But while there was a surge in demand for Y2K transitions, that was the last full time COBOL job I had. Ever since, I’ve only been offered temp assignments, mostly quite far away. Even today, I can sign on for a 6 month contract to fix someone’s problem, get no benefits, and be sent on my way again. The want ads are full of them.
Part of the issue is the overall switch away from full time jobs with benefits towards hourly work with no healthcare. So, I’ve been unemployed/retired for 8 years and I turn down the recruiters who still call me.
Perhaps once I’m the last qualified COBOL programmer on Earth, I might see a reasonable offer.
13 Likes
You are quite correct. I got my start professionally as a COBOL programmer and in tech school, close to a quarter of the time was spent learning how a business operates: double entry book keeping, cash flow and a lot of other related things beyond the coding.
Very tough tech school, forty hours a week for three months plus tons of homework. Less than half who started the class graduated and some who funked out still got hired by major companies.
The Space Shuttle was built with COBOL (I worked on the main parts database for two years 79 to 81).
We did more in 32k than most could now imagine and even the heavy iron back then ran it all in 16 meg with 150 concurrent users.
6 Likes
