Why COBOL Isn't the Problem

With old systems the catches always seem to be knowing the deep hidden why's to the encoded business rules and all the bugs, not just the high level goals and basic code.

Older systems have tons and tons of business logic encoded in them to handle edge cases and those functions will be in odd places, and then downstream systems have tons of logic in them to handle (and expect) bugs that your original system has.

Saying "let's rewrite a System that does X" is fine, but you also need to know all the arcane business rules and weird bugs in the system that aren't nicely spelled out in docs, or requirements, or some config file, but are nested deep deep inside in the app, hidden in unexpected places. The complex interactions of these functions generates the complexity, not just "Cobol". 50 years of rushed additions of weird rules to handle years past incidents or business logic changes.

Especially with old finance, insurance, and other systems that have this sort of longevity the original people who knew the why's have long since left. Any attempts to optimize, fix rules, fix bugs etc will produce a beautiful new clean system that's performant and simple and doesn't work at all.

The problem is that the business processes (A) are not understood, (B) are not deterministic, (C) are too complicated to implement in maintainable code (in any language). Everything flows from the effort to conceal these facts. That is the reason for the market dominance of IBM, and Oracle, and Microsoft: they are effective as partners in concealment.

The post misses the advantages of other languages, specifically to make this easier:

> Once you know how to program, learning programming languages is easy. Understanding existing programs is hard. Maintaining existing programs (in the form of what we call refactoring) is the most difficult part, by far.

Static typing, with generics etc means that you can use more proven libraries that are well-understood and not custom/special in each instance.

Immutable data-structures means you can reason about the function being applied without hidden side-effects, accelerating understanding of a new system and limiting unintended consequences, etc.

I worked about a decade in the 90's at a company providing code generation and source analysis tools to (banking, insurance, telco, etc) companies that used Cobol. The language can do everything (I've made Windows and OS/2 GUI programs with it), as can any Turing complete language, but it's not the best. The most I could say about it is that it's like Golang, where you're sort of steered away from over-complicating a program, but with Cobol you still don't have the tools to really simplify it either.

People who don't choose and use better tools are not part of the solution.

Note that NJ called for volunteers - in other words, free. The problem is that they just won’t pay for maintenance

The specific problem with COBOL is that COBOL is both a language that was badly designed on the day it was created and that there is a stigma against programmers who have worked with it. This stigma is also a problem for other languages such as Visual Basic and PHP and it can make it harder to find programmers willing to work in those languages. Nobody wants to be "unemployable" because they worked in a stigmatized programming language even though the idea of stigmatizing programming languages is objectively idiotic.

This wouldn't be a problem if organizations that are still using COBOL code would pay high salaries for COBOL programmers because there are people who are only writing code for the money who'd be happy to work with a terrible programming language if it makes them money. But they generally also want to pay antiquated salaries from decades ago for COBOL jobs if they even offer a salary at all. Because they would have migrated their system off of COBOL decades ago if they actually cared about properly maintaining it!

I think `COBOL` is (nowadays) a catch-all term for `COBOL` &/ `IBM assembler` &/ `IMS/hierarchical databases` and/or batch jobs. I can't fault a journalist for referring to all of that inexactly by `COBOL`.

Second, maintainability is absolutely not given freely. A gov't merely "purchasing software" does not necessarily get them the source code, let alone proper documentation. Seriously. Contractors have no incentive to make things easy for you, and all the incentive to make it hard. The tail often wags the dog.

"The powerpoint slides didn't say anything about lock-in" &c &c &c

>The New Jersey nightmare

I remember seeing articles that showed this specific issue was not COBOL itself, but the WEB front end(s) to that system. Seems they blamed COBOL for clicks.

> The real problem is, and always has been, the fact that the failed systems hadn't been maintained properly.

This is like Cyber Security on modern systems, cheap is always the way to go. Two different problems, same root cause. Management will always do it on the cheap.

All and all a very good article.

> Just kidding. We've never read "War and Peace" in any form.

That’s a pity. War and Peace is a fantastically good novel, genuinely a page-turner in places.

For people who don't know COBOL at all, are there any good resources/pages that explain its syntax and runtime?

The first stage is denial...

Bloomber's Odd Losts podcast had two episodes on the general topic (Jan 2023), "Why Corporate America Still Runs on Ancient Software That Breaks":

> Southwest Airlines had a disastrous holiday season, thanks in part to a software bug that left crews out of place and grounded thousands of flights. But Southwest isn't alone in having software in the headlines lately. The New York Stock Exchange recently had a software error that caused weird pricing on stocks and the FAA had its own computer issue that grounded planes earlier this month. So what's the deal with corporate software? Why do these crashes happen? And why does the user experience typically leave something to be desired? On this episode of the podcast we speak with Patrick McKenzie, an expert on engineering and infrastructure, who writes the Bits About Money newsletter and recently left payments company Stripe after six years. We talked about the challenges of keeping any software system alive after years of upgrades and updates, the distribution of tech talent across industries, and whether non-tech companies can close the gap with Silicon Valley.

* https://omny.fm/shows/odd-lots/why-corporate-america-still-r...

* https://www.youtube.com/watch?v=v6UQaXpzwQA

"This Is What Happens When Governments Build Software" (Jun 2023):

> There's a lot of frustration about the government's ability to build things in the US. Subways. Bridges. High-speed rail. Electricity transmission. But there's another crucial area where the public sector often struggles, and that is software. We saw it with the infamous rollout of Obamacare. We see it in the UX of the Treasury Direct website. And we saw it in the way state unemployment insurance systems broke during the pandemic. So why is it so hard for the public sector to build and maintain software? On this episode we speak with Jennifer Pahlka, the founder and former executive director of Code for America and author of the new book Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better, as well as Dave Guarino, who recently left the Department of Labor after working on upgrading the unemployment insurance system. Both have a long history of working on public sector software systems and they explain why the problem is so tricky.

* https://www.youtube.com/watch?v=nMtOv6DFn1U

One large component is that a lot of business rules and policies have been encoded into the software logic, and (re-)translating that into code in a new(er) language is part of the challenge.