3 ms·
>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the
by wredue 3y ago
>most of the business software that goes into said mainframe is in fact very simple and straightforward
Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush.
When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in that run which is a mess of gotos, global mutable state and basically every single other generally frowned upon software practice we know about, you start to understand the issues.
Moving off of mainframe is practically impossible because of it. That other person being voted down is actually correct, nobody in the organization actually knows how any of it works.
When organizations try to transition away, what ends up happening is they get these insane promises of “5 years” from vendors (like IBM. Ask me how I know!), but then it takes 10 years to transition single systems.
Nothing is documented. So you have business people who have no clue how anything works providing high level work flows. But then there’s always 50 random edge cases or interactions they never considered cause the 40 year old code just does it.
IT contains most of the business knowledge, but the mainframe grey beards are… stubborn. The business hangs on to these people because they’re seen as insanely valuable, not realizing that the grey beards have actually been actively suppressing knowledge to only their hidden documents, and they’ve got 8 years till retirement and are going to make sure that their job exists at least until then by actively sabotaging efforts to change. But also, for some reason, the business manager love the saboteurs. It’s insane to watch.
- pmontra 3y agoWhat happens when there are new requirements? An example, fiscal legislation changes and programs dealing with money have to adapt. Of course a way out is to lobby for changes that don't touch the software, but what happens when the software must be touched?
- wredue 3y agoThe estimate for carbon tax legislation was 700 hours and it took 1600 hours and didn’t work correctly for 9 months following. Edit: and for the record, at that point, we were already splitting off carbon transactions for their own processing because, surprise, energy has lots of regulation.
- znpy 3y ago> Ask me how I know! how do you know?
- mschuster91 3y ago> But also, for some reason, the business manager love the saboteurs. It’s insane to watch. Because they keep the shit running. If you're a bank and responsible for trillions of dollars in assets and billions of dollars in daily transactions, the absolutely last thing you can afford is downtime or, even worse, data loss. You'll not just have to handle a ton of angry customers, but in the worst case attract regulatory attraction or getting dragged in front of Congress and the courts. Here in Germany, Deutsche Bank is integrating 12 million accounts from Postbank to their own IT systems, and it has been an utter utter shitshow [1], attracting a lot of bad press and the banking regulator BaFin is also investigating [2]. [1] https://www.merkur.de/leben/geduldsprobe-fuer-postbank-kunden-wegen-it-umstellung-zr-92364511.html https://www.merkur.de/leben/geduldsprobe-fuer-postbank-kunde... [2] https://www.sueddeutsche.de/wirtschaft/deutsche-bank-postbank-unity-verbraucherschuetzer-1.6041602 https://www.sueddeutsche.de/wirtschaft/deutsche-bank-postban...