3 ms·

> the money to do the change simply wasn't there. This is a good excuse for a few years. But after decades? And talking about banks? --- The whole software

by mamcx 10y ago

> the money to do the change simply wasn't there. This is a good excuse for a few years. But after decades? And talking about banks? --- The whole software industry is frankly pathetic. We are talking about actors with the HIGHEST profits of mankind, and yet "we don't have money for this" star to look pathetic. Google, Apple, MS, IBM, Oracle, Banks, Defense industry, etc have not excuse to not invest in basic infrastructure. This is the same thing with country that neglect self-investment in fundamentals. If you agree is smart to invest in road, electric grid, etc, then why we think otherwise when we talk about OUR industry.?

wahern 10y ago
Talk is cheap and rarely includes a full accounting of real-world constraints. You can tell what a person's _real_ priorities are by what they do. Likewise, you can tell what a society's real priorities are by what they do.
- mamcx 10y ago
  >Talk is cheap and rarely includes a full accounting of real-world constraints. Of course. But after decades of the same problem, is not time to admit that is time to change?
  - wahern 10y ago
    Everybody always complains about the weather but nobody ever does anything about it. In other words, even though everybody complains about something, and even though it's theoretically fixable, the cost+benefit isn't always there. That doesn't stop people from complaining or offering conceptual solutions. If nobody pursues a particular solution, that's strong evidence about the real implementation and problem costs. Not conclusively, of course. But as a passive observer it's usually the best evidence available. Really, the answer to the COBOL "problem" is obvious and it's what basically anybody familiar with it suggests: a piecemeal and gradual shift according to cost, benefit, and opportunity.
nikdaheratik 10y ago
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 10y 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.

by mamcx 10y ago

wahern 10y ago

Talk is cheap and rarely includes a full accounting of real-world constraints. You can tell what a person's _real_ priorities are by what they do. Likewise, you can tell what a society's real priorities are by what they do.

mamcx 10y ago
>Talk is cheap and rarely includes a full accounting of real-world constraints. Of course. But after decades of the same problem, is not time to admit that is time to change?
- wahern 10y ago
  Everybody always complains about the weather but nobody ever does anything about it. In other words, even though everybody complains about something, and even though it's theoretically fixable, the cost+benefit isn't always there. That doesn't stop people from complaining or offering conceptual solutions. If nobody pursues a particular solution, that's strong evidence about the real implementation and problem costs. Not conclusively, of course. But as a passive observer it's usually the best evidence available. Really, the answer to the COBOL "problem" is obvious and it's what basically anybody familiar with it suggests: a piecemeal and gradual shift according to cost, benefit, and opportunity.

nikdaheratik 10y ago

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 10y 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.