3 ms·

It's not 10 years, it's probably closer to 100. Reasons being a) the ridiculously large cost of rewriting and testing the new system on a real-time system that

It's not 10 years, it's probably closer to 100. Reasons being a) the ridiculously large cost of rewriting and testing the new system on a real-time system that can't be taken down, and b) the ridiculously low cost of maintaining the current systems.

scrollaway 10y ago
How do newer banks do it? It certainly doesn't take 100 years to bootstrap a bank. I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. I can't find the post now, but some folks from the US govt who frequent HN talked at length about the ongoing replacement of mainframe-type services with newer tech. What I gathered from that is that the cost isn't ridiculously low at all when you take into account the impact it has on the organization's ability to get things done.
- lovich 10y ago
  While I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
- lovich 10y ago
  While I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
- eggestad 10y ago
  most moves from mainframe to *nix, windows or others are a port of existing code to a new OS. NOT a complete rewrite.
- semi-extrinsic 10y ago
  > I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. What you have to remember is that when the COBOL code was written, it replaced hundreds, maybe thousands of people doing manual data entry and manipulation, maybe even pen-on-paper. That gives you a fantastic ROI. After that's been done, replacing one computer system with a newer one is completely different, a spectacular case of diminishing returns.
- GFischer 10y ago
  I'm not sure about most banks, but some use other industry-specific software, there's one being developed in Uruguay for small banks and financial companies called Bantotal, which is written in Genexus, a 4GL language or metalanguage that generates whichever language you want (Java, Ruby, .NET, even Cobol and RPG) http://www.bantotal.com/?lang=en http://www.bantotal.com/?lang=en https://en.wikipedia.org/wiki/GeneXus https://en.wikipedia.org/wiki/GeneXus
- jetti 10y ago
  I had the fortune to work on COBOL software for brief period of time at my last job, which was at a financial clearing company. This group of 50+ COBOL applications that was the lifeblood of the company and a bad run could cost the company millions. The software was started in the early 90s, so it was easily 20+ years old when I was working on it. There was very little documentation regarding the process and the people who worked on the system were gone. I bring this up because when you have software that old you typically aren't going to have the original people who wrote it at the company nor will you have the people who gathered all of the requirements. All of the knowledge that went into that product was virtually gone. You are at a known state but you now have to re-create the steps to get to that known state as I'm sure a lot of the domain knowledge around the product is not there anymore. Not only that, you now most likely have other sources consuming the output of the original COBOL application so you have to ensure that the other applications are able to consume the new data and that those don't break either.

scrollaway 10y ago

How do newer banks do it? It certainly doesn't take 100 years to bootstrap a bank. I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. I can't find the post now, but some folks from the US govt who frequent HN talked at length about the ongoing replacement of mainframe-type services with newer tech. What I gathered from that is that the cost isn't ridiculously low at all when you take into account the impact it has on the organization's ability to get things done.

lovich 10y ago
While I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
lovich 10y ago
While I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
eggestad 10y ago
most moves from mainframe to *nix, windows or others are a port of existing code to a new OS. NOT a complete rewrite.
semi-extrinsic 10y ago
> I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. What you have to remember is that when the COBOL code was written, it replaced hundreds, maybe thousands of people doing manual data entry and manipulation, maybe even pen-on-paper. That gives you a fantastic ROI. After that's been done, replacing one computer system with a newer one is completely different, a spectacular case of diminishing returns.
GFischer 10y ago
I'm not sure about most banks, but some use other industry-specific software, there's one being developed in Uruguay for small banks and financial companies called Bantotal, which is written in Genexus, a 4GL language or metalanguage that generates whichever language you want (Java, Ruby, .NET, even Cobol and RPG) http://www.bantotal.com/?lang=en http://www.bantotal.com/?lang=en https://en.wikipedia.org/wiki/GeneXus https://en.wikipedia.org/wiki/GeneXus
jetti 10y ago
I had the fortune to work on COBOL software for brief period of time at my last job, which was at a financial clearing company. This group of 50+ COBOL applications that was the lifeblood of the company and a bad run could cost the company millions. The software was started in the early 90s, so it was easily 20+ years old when I was working on it. There was very little documentation regarding the process and the people who worked on the system were gone. I bring this up because when you have software that old you typically aren't going to have the original people who wrote it at the company nor will you have the people who gathered all of the requirements. All of the knowledge that went into that product was virtually gone. You are at a known state but you now have to re-create the steps to get to that known state as I'm sure a lot of the domain knowledge around the product is not there anymore. Not only that, you now most likely have other sources consuming the output of the original COBOL application so you have to ensure that the other applications are able to consume the new data and that those don't break either.