Banks remain with COBOL because it's unsexy and stable. And then they say... let's just YOLO some vibe code into the next release sight unseen! Logic checks out.

▲

whynotmaybe an hour ago | parent | next [-]

Banks remain on COBOL because of the quantity of code that's been tested in real life situation for decades.

Yes IBM license for mainframe are expensive but it never fails.

I worked on a migration project where only the tests would take a few thousand days.

Yes they could be automated, but the regulations in place required that a human sign that all the test were executed at least once by a human.

	▲	captain_coffee 43 minutes ago \| parent [-]
		What do you mean "only the tests would take a few thousand days"? Did running the test suite take 10 years? Like literally what exactly do you mean?

▲

themafia 3 hours ago | parent | prev | next [-]

They stick with COBOL because it runs well on the mainframe. The mainframe and sysplex architecture gives them an absurd level of stability and virtualization that I don't think the rest of the market has nearly caught up to yet. Plus having a powerful and rugged centralized controller for all of this is very useful in the banking business model.

▲

Betelbuddy 2 hours ago | parent [-]

This is the reason. IBM Mainframe business grew 60%. The modern mainframe is the best state of the art platform for computing, in both reliability and efficiency.

	▲	ASalazarMX an hour ago \| parent [-]
		Also, IBM mainframes are wonderfully isolated from physical hardware. They could change processors in the next model, and users would notice a small delay as binaries were recompiled on-the-fly the first time it was used. They surely could extract more performance from the hardware by shedding layers, but prioritized stability and compatibility.

▲

bpodgursky 3 hours ago | parent | prev [-]

Banks remain with COBOL because they have a fuckton of COBOL code and 4 people can write it. There's nothing more to it.

Now, 4 million people can write it.

▲

notepad0x90 3 hours ago | parent | next [-]

I don't think learning how to write COBOL was ever a problem. Knowing that spaghetti codebase and how small changes in one place cause calamity all over the place is. Those 4 people's job is to avoid outages, not to write tons of code, or fix tons of bugs.

▲

ASalazarMX an hour ago | parent | prev | next [-]

In my experience, learning COBOL takes you a week at most, learning the "COBOLIC" (ha ha) way of your particular source base will take you a couple of months, but mastering it all including architecture will take you a year, half a year if you're really good.

One year from zero to senior doesn't sound that hard, does it? Try that with a Java codebase.

▲

mikepurvis 3 hours ago | parent | prev | next [-]

I would say more significantly, 4 million people can read it. The changes required for any given quarter are probably miniscule, but the tricky part is getting up to speed on all those legacy patterns and architectural decisions.

A model being able to ingest the whole codebase (maybe even its VCS history!) and take you through it is almost certainly the most valuable part of all.

Not to mention the inevitable "now one-shot port that bad boy to rust" discussion.

▲

happycube 3 hours ago | parent [-]

You also need "make no mistakes"

	▲	Jare 2 hours ago \| parent [-]
		Run both systems side by side for 9 months. Banks have patience.

▲

a456463 3 hours ago | parent | prev | next [-]

I would have you nnowhere near my production

	▲	a4isms 2 hours ago \| parent [-]
		Or production for the bank with my savings.

▲

SirFatty 3 hours ago | parent | prev [-]

It's got to be a lot more than 4. Global Shop (ERP) is written in Visual COBOL.