Submitted via IRC for TheMightyBuzzard
We reached out to Daniel Döderlein, CEO of Auka, who has experience with working with banks on technological solutions such as mobile payments. According to him, COBOL-based systems still function properly but they're faced with a more human problem.
This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology — which in itself is fine — if it weren't for the fact that the people servicing that technology are a dying race.
And Döderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language.
And here I thought everyone knew banking software should be written in PHP, javascript, or a combination of the two.
Source: https://thenextweb.com/finance/2017/04/25/banks-should-let-ancient-programming-language-cobol-die/
(Score: 2, Insightful) by Anonymous Coward on Saturday April 29 2017, @11:02AM (6 children)
How about these trillion dollar buisnesses TRAIN THE REPLACEMENTS.
(Score: 2) by turgid on Saturday April 29 2017, @04:09PM (4 children)
If you can convince the shareholders they'll see a return on their investment in the next four quarters, by all means run it by them.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday April 30 2017, @12:11AM (2 children)
Then on top of that. These are the sort of systems that *MUST* run. I mean if they fuck up entire large multi national companies will go under in 1-2 weeks due to the fact they would not be able to pay anyone or transact business. When they said to big to fail. They meant it.
The technical people are keenly aware of the monster. They *DO* *NOT* *FUCK* with it. Tech debt is a mountain that will never be undone.
Money is not really the problem. These large banks have thousands of competent programmers. The problem is how do you replace the engine of a car that is driving 200 MPH. There is decades of tech debt in there. Some of these banks have been chewing on their tech stacks since the 60s.
(Score: 3, Insightful) by kaszz on Sunday April 30 2017, @04:09PM (1 child)
Build a new engine that traffic is redirected to bit by bit. After extensive testing of course, like sitting in parallel and comparing results for 2 years.
(Score: 2) by Justin Case on Sunday April 30 2017, @08:11PM
The COBOL environments I worked in didn't have "traffic" to "redirect". Those barfwords showed up when the marketdroids figured out the web could be used for advertising*.
However I can imagine someone cobbling together a web front end with an interface to a COBOL back end, which I would expect to be an abomination you couldn't pay me enough to touch.
* Also known as "the end of modern civilization".
(Score: 0) by Anonymous Coward on Sunday April 30 2017, @04:22PM
If your looking 4 quarters ahead, you are far, far too visionary for American business.
(Score: 4, Interesting) by tibman on Saturday April 29 2017, @05:02PM
The difficulty is in explaining to HR and your superiors that you are hiring someone who literally cannot do the job (yet). They cannot comprehend it.
I was recently promoted into a position where i can hire. Last month i hired a green guy who has been teaching himself (and attending a "code school"). Probably won't be very productive for several months. Also hired a lady who had a kid and took a few years off work. She said nobody would give her the time of day. Both have a real passion for programming. I'd rather hire someone who isn't burnt out and needs some training than someone who doesn't give a shit about their work but is technically very experienced. So far the company is cool with us training/teaching greener people. I think they're cool with it because greener people are cheaper, hah.
SN won't survive on lurkers alone. Write comments.