4 ms·

It cost Commonwealth Bank of Australia a ~$1 Billion to convert their old system from COBOL (http://www.reuters.com/article/us-usa-banks-cobol-idUSKBN17C0D8 htt

It cost Commonwealth Bank of Australia a ~$1 Billion to convert their old system from COBOL (http://www.reuters.com/article/us-usa-banks-cobol-idUSKBN17C0D8 http://www.reuters.com/article/us-usa-banks-cobol-idUSKBN17C...). That took them 5 years and they're about a third of the size of most of the larger US banks. So you're asking for 20-30 banks to devote 5% of their operating costs over the next 5 years just to fix the problem in the U.S. Or they can put the problem off for another few years and see what happens. This isn't a "basic infrastructure" problem, it's a problem where the people writing the software didn't plan for obsolescence and many of the "best practices" we take for granted weren't even in place when this was being written. And it is about tracking real money, so if the system isn't exactly right, they could end up being tied up in court which makes it even tougher.

mamcx 9y ago
The whole article clearly show that is justified. The risk is too high to let things as is today. --- BTW, probably some downvoters think I'm advocating to move this to some hipster language like JS or something like that. I work mostly for enterprise-alike customers, have work for government projects, etc. So I'm aware of the work here. Also, have helped to move decent-sized code bases, several times, from OLD->NEW. > ~$1 Billion to convert their old system If things in AU is alike my country, this cost is inflated... For some project Oracle bid our customers 10x more than ours at the time. But this is beside the point, anyway. --- So, how this could be done? ==== The first problem is the need to have a solid hardware+OS, where linux is not there. Solution? Stay on mainframes. Is basic. The second problem is OLD cobol + Zero understanding in why, how, where, etc is the full system. This is the big one. This is alike find a OLD C codebase, made like 3 years ago. Or even better, a OLD B codebase (or any kind of precursor to C, if it exist at the time...). And pretend the solution is to STAY WITH THE OLD CODEBASE. For DECADES. IS THIS MADDNESS! NOT, IS IT!!!! -- So, you build a better COBOL. Like CoffeScript->Js. You star moving the code from OLD to NEW. In the process, you document, and build testing. You end with a better cobol (or a transpiler) with a proper toolchain. ---- This can be look as the progress with another bad language, JS. You start with something terrible, with a huge installed base, yet, you star moving torwards something else. In the process, you can do something alike ASM.js but for cobol, and whola, you can transpile other languages.
- mamcx 9y ago
  BTW, I can't imagine that IBM or somebody else have not figure a technological solution to this. The main trouble is that customers on the enterprise side of the world have no respect for developers, and fired them after years or just not care. Then, when in trouble, ask for external contractors that do not have the required knowledge (and maybe, not even the skills). For this to work, it need to engage the on-site developers + maybe contractor or hire some additional hands for the mechanical work. Do it well, and this is fairly cheap for the benefit. But this require to "do it well". And that is the "hard" part, because is the human factor the big issue here.

mamcx 9y ago

The whole article clearly show that is justified. The risk is too high to let things as is today. --- BTW, probably some downvoters think I'm advocating to move this to some hipster language like JS or something like that. I work mostly for enterprise-alike customers, have work for government projects, etc. So I'm aware of the work here. Also, have helped to move decent-sized code bases, several times, from OLD->NEW. > ~$1 Billion to convert their old system If things in AU is alike my country, this cost is inflated... For some project Oracle bid our customers 10x more than ours at the time. But this is beside the point, anyway. --- So, how this could be done? ==== The first problem is the need to have a solid hardware+OS, where linux is not there. Solution? Stay on mainframes. Is basic. The second problem is OLD cobol + Zero understanding in why, how, where, etc is the full system. This is the big one. This is alike find a OLD C codebase, made like 3 years ago. Or even better, a OLD B codebase (or any kind of precursor to C, if it exist at the time...). And pretend the solution is to STAY WITH THE OLD CODEBASE. For DECADES. IS THIS MADDNESS! NOT, IS IT!!!! -- So, you build a better COBOL. Like CoffeScript->Js. You star moving the code from OLD to NEW. In the process, you document, and build testing. You end with a better cobol (or a transpiler) with a proper toolchain. ---- This can be look as the progress with another bad language, JS. You start with something terrible, with a huge installed base, yet, you star moving torwards something else. In the process, you can do something alike ASM.js but for cobol, and whola, you can transpile other languages.

mamcx 9y ago
BTW, I can't imagine that IBM or somebody else have not figure a technological solution to this. The main trouble is that customers on the enterprise side of the world have no respect for developers, and fired them after years or just not care. Then, when in trouble, ask for external contractors that do not have the required knowledge (and maybe, not even the skills). For this to work, it need to engage the on-site developers + maybe contractor or hire some additional hands for the mechanical work. Do it well, and this is fairly cheap for the benefit. But this require to "do it well". And that is the "hard" part, because is the human factor the big issue here.