Thread by @lzsthw

Back in the day programmers used to talk endlessly about how awesome banking programmers were. "They handle TRILLIONS of transaction in COBOL!" Then the web came along and their websites were atrocious so we figured out, nah, they suck. Even today, we can clearly see it.

For example, today I had to send someone money. My bank decided that the phone number and email I'd been using for close to a decade wasn't correct, so it made me enter it again, only it just made me select it again, then it complained that I couldn't send the money anyway? WAT?

I had to go into my recurring payments and find the entire series that I use to reliably pay my bills, remove the series, and then update the target person's email and phone too. Then I could go back and send the money, oh except I couldn't.

The other person gets a text message that they have to register with Zelle, something we've *never* used in the past. Everything was working just fine and now we're forced to switch to this. I have to then walk them through doing the exact same update, only problem is...

They have an old email on file so they had to use their phone number, but that conflicted with the existing phone number that's in the bank's so we had to delete the previous account and then add it back with Zelle, oh and approve it and agree to all kinds of Zelle things.

Finally, after mulitple text messages and approving phone numbers that were already approved the money is received and then...sits in Zelle...pending. I don't have the money, they don't have the money, Zelle has the money, what? Can you imagine if Twitter or Facebook did this?

"I'm going to send a message to my friend on Twitter. Oh boy it says it was sent, but now it's stuck in limbo and they don't receive it for 24 hours."

No way, people would revolt and laugh in your face if you did that. Banking coders though?

"Well darn. We have to take Zed's money and transmit it through an IBM S/390 running a CICS translation to COBOL emulation of a 3270 terminal and print it out and then in 24 hours we can give that to Zelle."

Why do they do this? Because they believe mainframes are "safe".

Despite 50 or 60 TRILLION transactions/day of money on just a few modern platforms using plain old SQL stupid banking programmers think money has to go through a slow ass COBOL system or it's not "safe". No explanation of what safe is or how no modern company needs this.

They're proud of their CICS/COBOL code too. I had them walk in with a 10" thick stack of fan-fold green lined printout paper (you remember that) proclaiming how hardcore they were because they wrote CICS code that generated *that much* COBOL. I asked what it did...one screen.

That's right, these master geniuses of the programming world with their hardcore hacker CICS code had to use an 10" thick stack of COBOL to make one screen work, meanwhile I could code the same screen in raw C and curses in an afternoon and it'd be 200 lines tops.

They're also insanely proud of how much money they waste. That 10" stack of CICS/COBOL required like 30 programmers working for weeks at something like $500/hour. The scale of the waste is astronomical, and then the end result is just absolute garbage.

So, you want to know why my bank is making me enter all this crap in again?

I'll bet you that they can't actually get my data out of their little Horror House of COBOL and into Zelle, so instead of doing that they just make me enter it again and feed it directly to Zelle.

This is why I think any future bailouts of the Financial sector should be done the way we bailed out US cars in the 70s. In the 70s we had an oil crises because US car manufacturers made junk cars that got 3 miles to the gallon of gas, and OPEC could free market gouge us.

US auto manufacturers didn't want to modernize, so the government tied forced upgrading to receiving the tariffs and bailouts they desperately needed. We demanded cars be fuel efficient in exchange for trade concessions to save them, so why not do that with banks?

Since so many banking failures and collapses can be tied to mountains of terrible COBOL let's treat COBOL Mainframes like Gas Guzzling Mustangs. If you want a bailout then you've got 10 years to remove all COBOL from your systems and modernize mainframes or stop using them.

Now, you don't even need to abolish COBOL. You could make the equivalent of "cars need to be at 20 miles/per gallon by 1980" simply "All transactions are visible to the user in under 1 second by 2030." But I personally think they'll *still* find a way to keep COBOL then.