4 ms·

Banks have tons of things going on, I wouldn't take one (or even a hundred) job postings as indicative of a firm-wide shift in strategy. They could be using Rus

by lmkg 4y ago

Banks have tons of things going on, I wouldn't take one (or even a hundred) job postings as indicative of a firm-wide shift in strategy. They could be using Rust for their phone app or their real-time ML fraud-detection system, while he checks are still processed by a piece of software whose source code is COBOL whose only extant copy was written by typewriter in 1975.

onlyrealcuzzo 4y ago
This isn't serious is it?! I find it hard to believe banks are running critical code they didn't at least back up somewhere. I also don't understand why it would be hard to back up the code.
- walnutclosefarm 4y ago
  I can't tell you how common it was or is, but I can tell you that I worked with at least two banks in Europe in the early 2000s that were rewriting core transaction processing and routing systems that were originally written in COBOL, and for which they had lost the source code. They patched the systems when necessary by patching the object code in assembler. The systems were 30 odd years old at the time. Nobody seemed to be able to explain how the source code was lost, other than that it had something to do with corporate mergers and acquisitions. The fact that they were spending millions to rewrite them was an indication of unsatisfactory they found the situation to be.
  - jamesfinlayson 4y ago
    > They patched the systems when necessary by patching the object code in assembler. If that sort of development can't force a rewrite then nothing will.
- cratermoon 4y ago
  When it was last compiled from source, the source was punched cards. They were placed in a file somewhere and ended up either getting thrown out as part of a data retention move or shipped off to Iron Mountain to be lost among billions of other boxes.
- Spooky23 4y ago
  Those systems are usually boring things that never get modified. Ledgers, etc. The tasks required to process checks are the same as they were in 1975. The inputs and outputs just changed. Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go. The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario. Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.
- jamesfinlayson 4y ago
  I'm sure they do, but decent version on some of these ancient systems would be... challenging. I've worked at a company that uses some pretty ancient hardware (emulated these days) for which I think there is a git client, but I don't think it works so well, so they used some equally ancient version control system.
- Kamq 4y ago
  Version control practices have changed a lot since the 70s. It's possible the code has actually been lost. Or, more likely, the version that actually runs has been lost. Some code still exists (or existed), but how exactly it differs isn't exactly known, and deploying it would require getting a higher up to sign off on, essentially, unbounded risk for their critical systems (they will never do this). If that happened in the 80s or 90s the code that exists has probably diverged enough that it's effectively pseudocode at this point.

by lmkg 4y ago

onlyrealcuzzo 4y ago

This isn't serious is it?! I find it hard to believe banks are running critical code they didn't at least back up somewhere. I also don't understand why it would be hard to back up the code.

walnutclosefarm 4y ago
I can't tell you how common it was or is, but I can tell you that I worked with at least two banks in Europe in the early 2000s that were rewriting core transaction processing and routing systems that were originally written in COBOL, and for which they had lost the source code. They patched the systems when necessary by patching the object code in assembler. The systems were 30 odd years old at the time. Nobody seemed to be able to explain how the source code was lost, other than that it had something to do with corporate mergers and acquisitions. The fact that they were spending millions to rewrite them was an indication of unsatisfactory they found the situation to be.
- jamesfinlayson 4y ago
  > They patched the systems when necessary by patching the object code in assembler. If that sort of development can't force a rewrite then nothing will.
cratermoon 4y ago
When it was last compiled from source, the source was punched cards. They were placed in a file somewhere and ended up either getting thrown out as part of a data retention move or shipped off to Iron Mountain to be lost among billions of other boxes.
Spooky23 4y ago
Those systems are usually boring things that never get modified. Ledgers, etc. The tasks required to process checks are the same as they were in 1975. The inputs and outputs just changed. Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go. The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario. Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.
jamesfinlayson 4y ago
I'm sure they do, but decent version on some of these ancient systems would be... challenging. I've worked at a company that uses some pretty ancient hardware (emulated these days) for which I think there is a git client, but I don't think it works so well, so they used some equally ancient version control system.
Kamq 4y ago
Version control practices have changed a lot since the 70s. It's possible the code has actually been lost. Or, more likely, the version that actually runs has been lost. Some code still exists (or existed), but how exactly it differs isn't exactly known, and deploying it would require getting a higher up to sign off on, essentially, unbounded risk for their critical systems (they will never do this). If that happened in the 80s or 90s the code that exists has probably diverged enough that it's effectively pseudocode at this point.