Articles like these point to a multi-decade old language when something fails. Sometimes they don’t even wait for the post-mortem. There’s COBOL involved, so it must be COBOL. It’s old, right? First, let’s get one thing out of the way, and that’s the implication that the language is 60+ years old, so the computer it’s running on is old, right? No, it’s likely running on a modern IBM mainframe with modern tools. IBM makes the promise that if you write a mainframe program today, you can run it on future mainframes, without modification. That’s great for business customers because re-writing working software is expensive and time-consuming. These are highly reliable machines that are intended to run with down-time measured in seconds per year.

But the software failed, right? Because it’s old. That is complete balderdash. If you write a correct program today, it will continue to be a correct program 100 or 1,000, or 10,000 years from now. If you have an interest rate, and an amount, and compound that over a period of years, that answer won’t change. Because the program itself is applied math and logic. The rules of logic and math don’t change over time. Time itself isn’t the issue. What is the issue?

The issue comes back to maintenance. If I write a program that works today, it may not be completely correct. There may be bugs. Those need to be fixed and the effort I put toward fixing the bug impacts the long-term stability of the program. If fixing a bug is done under the gun, or on the cheap, it might cause what’s called “code entropy.” Code entropy is the de-evolution of a well written program into crap. Sometimes the bug fix must be rushed through, as customers are losing money by the minute. After that, we should go back and do a broader fix to the software. That may mean making changes to the underlying logic or other parts of the program. In doing so, we minimize the code entropy problem. But that maintenance cost money.

The next reason for maintenance is a change in requirements. This is especially true for systems that change every time there’s a change in the law. In some cases these changes are retro-active. This creates a lot of churn on short time-lines, and like bug fixes, and also results in code-entropy. The quick fix is rarely followed by the work to refactor the existing code, accordingly. The software entropy increases and the code becomes even harder to fix with the next change. Re-architecture of the old code costs money. Most places just indefinitely defer the maintenance on their old COBOL code.

Many commercial, private sector, companies rely on COBOL for high-volume transaction processing. It has many features more modern languages lack, like it’s English-like structure is legible to non-programming auditors. And modern features have been added to it, even if they have not been adopted by organizations using COBOL (especially the ones likely to skimp on maintenance). But it is not a truly modern language like Rust or Go, or even a middle-aged language like Java. And it exists in a specific computing environment (the mainframe) which is kept artificially expensive thanks to its monopoly supplier and small customer base. Getting trained on mainframe operations isn’t cheap and many companies don’t want to pay for it, as their newly trained people will leave for better offers.

Many of the problems people associate with COBOL are going to re-appear (and have re-appeared) when companies move to platforms like Java. I have been at many sites were Java programs on old, unsupported versions of Java are being poorly maintained. Or running on old, out of support application servers (programs that run Java code on servers). Databases that are so old and out of date that either the vendor has gone out of business or there is no longer a way to upgrade their database to the current versions. When out of date, poorly written Java code crashes, it just becomes a generic, bland, IT failure and mismanagement. But, because it doesn’t involve COBOL, it doesn’t get the headlines that are cheap and easy to score with an old language.

The biggest counter-example of “because COBOL” is the number of banks, brokerages, exchanges, payment processors, and insurance companies that quietly process about 80% of the worlds financial transactions on a daily basis. They have an incentive to perform routine maintenance. They have also quietly off-shored their software maintenance over the last few decades to places where a COBOL coding jobs is a good job. Offer most US software engineers a COBOL job and they will turn their nose up and assume you were joking. But in India, the Philippines, and China, COBOL is not the scarlet A that it is in the West.

I want to address something specific about the article posted above. It stated that because COBOL is by its nature defective or tool old, it cost the US 40 billion in GDP. That sounds like a lot, but in an economy generating trillions of activity, it is a rounding error. Second, re-writing that code has its own costs. That could be even more billions spent getting exactly to the same level of service provided today. There probably isn’t enough money in the world to re-write the existing, mission critical COBOL code into something else. That will take away from other budgets and, if not maintained, will result in the same problem just 10, 20, or 30 years in the future. And where will publications like FT get cheap headlines in the future, if COBOL goes away?