Anyone want to hire an old man who knows COBOL?

Seven years ago, I was citing the fact that 43% of the global financial system runs on a computer language no-one speaks anymore. Seven years later, PC Magazine (are PC’s still a thing?) picked up on this theme with the headline:

The World Depends on 60-Year-Old Code No One Knows Anymore | PCMag

… and sub-headline:

Every day, 3 trillion dollars worth of transactions are handled by a 64-year-old programming language that hardly anybody knows anymore.

The column cites a recent (2022) report from the International Journal of Advanced Research in Science, Communication and Technology (IJARSCT), which not only claims that 43 percent of all banking systems are still using COBOL, but that 95 percent of all ATM activity in the US, and 80 percent of all in-person credit card transactions are managed by such systems.

Is this a critical potential failure point that is systemic in the system … or is it a critical reliable and secure base infrastructure that should be left untouched?

I can see arguments on both sides of the house.

For the innovators, they detest the idea of mainframes, old code, legacy systems and everything pre-last year. They are always looking to the future, replacing the old with the new. For the risk averse, any change to core systems is creating massive potential for failure, and so things should be kept the same – maintain the status quo – as far as possible.

There is no right or wrong here, except to say there has to be a meeting of minds. Old systems create as much risk as new. If you are running the core, global operations of the financial system on code no-one writes or understand anymore, that’s a huge risk. It’s why old COBOL programmers, who retired years ago, turn up at the bank’s headquarters driving a Ferrari. They are very well paid to maintain old stuff.

Equally, if you replace old code with new stuff, it creates massive exposures to failure as learned by the UK bank TSB, my favourite example of computer transformation failure. The bank upgraded its IT systems in April 2018 and failed to run sufficient testing and analysis. According to IT Pro, “this led to TSB’s banking services experiencing significant disruption across branch services, telephone, online, and mobile banking. All of the bank’s branches, and a ‘significant portion’ of TSB’s 5.2 million customers were affected. It took until December 2018 for the bank’s services to return to normal … the bank’s design, build, and testing of the platform … involved more than 1,400 people and 70 suppliers. This was described as unprecedented and incredibly complicated … in February 2019, the bank revealed the disaster had cost £330 million, with £125 million of the figure in customer compensation, £122 million for emergency recruitment, £49 million in fraud, and £33.5 million in uncollected fees.”

That was before the regulatory fines that amounted to almost £50 million more.

This debate is continual and constant: to change or not to change? Take the risk or avoid the risk? Does the avoidance of the risk create the risk itself?

This is a debate that will carry on until I die. In the meantime, if anyone is interested, I used to be a pretty good COBOL programmer. Happy to go back and refresh my memory, if it means I can buy a Ferrari.