4 ms·

The cost of running government on COBOL (h/t Cowen)

18 points by chkaloon 5y ago

tuatoru 5y ago
Fails to assess the cost of COBOL vs alternatives. Junk research.
- chkaloon 5y ago
  Looks like that's exactly what it does "The delays caused a 4.4 percentage point relative decline in total card consumption in COBOL states relative to non-COBOL states."
  - perl4ever 5y ago
    Any idea what "card consumption" is? I don't think they mean punched cards.
    - chkaloon 5y ago
      I assume debit cards
      - deleted 5y ago
        [deleted]
France_is_bacon 5y ago
I've read about this COBOL argument. I'm not an expert, so I might be wrong on the details. The deal is that COBOL has native fixed point math. Floating point just doesn't work. So, .1 just not exist at all in floating point. See: https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/ https://www.exploringbinary.com/why-0-point-1-does-not-exist... Some have said that Java and other languages have libraries that can do fixed point math calculations. Yes, that is true. Java also does all it's fixed point math via library calls, which are much slower than native opcode support. And while it is fine for millions of transactions or hundreds of millions, when you are doing 2 billion or more transactions per second, like what happens in our financial systems, these external libraries just are not fast enough. The dilemma with migrating COBOL is not that you are migrating from one language to another, but that you are migrating from one paradigm to another. The edges of Java or python on Linux have a different shape than the edges of COBOL on a mainframe. In some cases COBOL may have allowed the application to extend past what modern languages can support. For those cases COBOL running on a modern mainframe will actually be the cheaper, more performant and more accurate solution. Also, COBOL works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars. Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business. Plus, how would you even update these kind of systems? They are running trillions of transactions per day. They are using very complex code. Take the insurance industry, for example. They have 50 states, each with different legal requirements for insurance, that change all the time, and by all the time, I mean daily, not yearly. So you have 40 or 50 years of code base, and most of it commented out or maybe just not called as a function anymore but still exists. So if you write brand new code, and you have a Fortune 100 insurance company that sends out billions of dollars in claims and investments daily, pays out life insurance, pays out money for accidents, workers comp, homeowners insurance, umbrella insurance, etc, and it is working great right now, if you are the CEO, are you going to convert your working system over to Java or c or whatever? And, there is just no way to test any system that replaces current COBOL programs, let alone the entire system, with all the different kinds of computers, technologies, etc, because it is not just the COBOL. It's the entire system. Just no way. Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps. And, actually, I read about one insurance company that looked into it, and hired IBM to do a feasibility study and if it was feasible, that they should do it. So IBM did the study, and despite the literally hundreds of millions of dollars they would clear to convert, they just said "F-ck it" and walked away. Who wants to take on that kind of liability if it doesn't work? Who wants to risk their company's reputation on something like that? Where all of a sudden, 85-year-old women are not getting their monthly annuity check and you have tens of thousands of them being kicked out of their homes because they are not getting their monthly annuity to pay their mortgage. What a nightmare. Rewriting all the COBOL code in another language, just to have a snazzier language, is super costly, extremely risky, and zero benefits. Using another programming language, just for the sake of using the other programming language is a complete waste of time and effort. Stockholders, CEOs, managers, hate big projects that offer no benefit. Examples: “I just got through a conversion to go from COBOL to Java,” Hinshaw said. “It’s taken them four years, and they’re still not done.” The Commonwealth Bank of Australia replaced its core COBOL platform in 2012, it took five years at a final cost of $749.9 million ($1 billion Australian). TSB, a UK bank, changed from a COBOL-based system in 2018 because of a buyout. The bank was unable to trade for days. The migration cost was $454 million. Engineering the actual migration was even more. TSB lost $68 million from financial fraud while its systems were melting down. Customer compensation for the systems being down was more than $172 million. The bank spent $168 million on new staff to deal with 204,000 customer complaints. The CEO resigned. TSB is still trying to fix the damage. It's very easy to tell someone else to switch languages when it's not your ass on the line. But if it IS your ass, there's a whole other look to it. As far as getting new programmers - that is no problem. COBOL is very easy to learn. It is very easy to train people up. And what programmer doesn't know more than one language anyways? It's just one more language.
wudangmonk 5y ago
They should toss it to the Rust community, they'll happily rewrite it in Rust, might not even need to pay them as long as you allow them to always tell everyone they are Rewriting it in Rust.
- mariuolo 5y ago
  As long as they will also take on the financial risk due to potential errors in their code.
cratermoon 5y ago
Anecdotal data point: I worked, as a consultant, with a team of COBOL programmers that had been sent to some kind of "Java in 21 days" course. The system they were in the process of writing when I came on board used the "float" type to store money. There was a point at which one of the programmers said he ignored the tests on amounts that were failing in reproducible ways because he thought they were wrong. To this day I don't know the full cost of replacing all the uses of float with BigDecimal, but I'm glad one of my fellow consultants had a math and finance background and was able to sort it out. Why did the COBOL folks use float and not know about the problems with IEEE-754 floating point?[1] Because they had been using COBOL, which, because it was purpose-built for business and accounting has fixed-point arithmetic, handles money naturally. 1. https://0.30000000000000004.com/ https://0.30000000000000004.com/
- jamesfinlayson 5y ago
  Good grief... it's not like IEEE 754 is new by any stretch.
  - cratermoon 5y ago
    Yes but if you've spent your career working in a programming language that just does the Right Thing (per business/accounting rules), and you're thrown into a project with a language you don't know and need to do money math, it's not unreasonable to expect, until told otherwise, that 0.1 + 0.2 = 0.3. The COBOL-turned-Java programmers I worked with may not have been the best (nor is Java all that), but the fact that COBOL does money the way we intuitively expect "out of the box" is why it remains in wide use. What other language has a built-in Money type that handles error accumulation and rounding the way accountants expect?

18 points by chkaloon 5y ago

tuatoru 5y ago

Fails to assess the cost of COBOL vs alternatives. Junk research.

chkaloon 5y ago
Looks like that's exactly what it does "The delays caused a 4.4 percentage point relative decline in total card consumption in COBOL states relative to non-COBOL states."
- perl4ever 5y ago
  Any idea what "card consumption" is? I don't think they mean punched cards.
  - chkaloon 5y ago
    I assume debit cards
    - deleted 5y ago
      [deleted]

France_is_bacon 5y ago

I've read about this COBOL argument. I'm not an expert, so I might be wrong on the details. The deal is that COBOL has native fixed point math. Floating point just doesn't work. So, .1 just not exist at all in floating point. See: https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/ https://www.exploringbinary.com/why-0-point-1-does-not-exist... Some have said that Java and other languages have libraries that can do fixed point math calculations. Yes, that is true. Java also does all it's fixed point math via library calls, which are much slower than native opcode support. And while it is fine for millions of transactions or hundreds of millions, when you are doing 2 billion or more transactions per second, like what happens in our financial systems, these external libraries just are not fast enough. The dilemma with migrating COBOL is not that you are migrating from one language to another, but that you are migrating from one paradigm to another. The edges of Java or python on Linux have a different shape than the edges of COBOL on a mainframe. In some cases COBOL may have allowed the application to extend past what modern languages can support. For those cases COBOL running on a modern mainframe will actually be the cheaper, more performant and more accurate solution. Also, COBOL works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars. Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business. Plus, how would you even update these kind of systems? They are running trillions of transactions per day. They are using very complex code. Take the insurance industry, for example. They have 50 states, each with different legal requirements for insurance, that change all the time, and by all the time, I mean daily, not yearly. So you have 40 or 50 years of code base, and most of it commented out or maybe just not called as a function anymore but still exists. So if you write brand new code, and you have a Fortune 100 insurance company that sends out billions of dollars in claims and investments daily, pays out life insurance, pays out money for accidents, workers comp, homeowners insurance, umbrella insurance, etc, and it is working great right now, if you are the CEO, are you going to convert your working system over to Java or c or whatever? And, there is just no way to test any system that replaces current COBOL programs, let alone the entire system, with all the different kinds of computers, technologies, etc, because it is not just the COBOL. It's the entire system. Just no way. Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps. And, actually, I read about one insurance company that looked into it, and hired IBM to do a feasibility study and if it was feasible, that they should do it. So IBM did the study, and despite the literally hundreds of millions of dollars they would clear to convert, they just said "F-ck it" and walked away. Who wants to take on that kind of liability if it doesn't work? Who wants to risk their company's reputation on something like that? Where all of a sudden, 85-year-old women are not getting their monthly annuity check and you have tens of thousands of them being kicked out of their homes because they are not getting their monthly annuity to pay their mortgage. What a nightmare. Rewriting all the COBOL code in another language, just to have a snazzier language, is super costly, extremely risky, and zero benefits. Using another programming language, just for the sake of using the other programming language is a complete waste of time and effort. Stockholders, CEOs, managers, hate big projects that offer no benefit. Examples: “I just got through a conversion to go from COBOL to Java,” Hinshaw said. “It’s taken them four years, and they’re still not done.” The Commonwealth Bank of Australia replaced its core COBOL platform in 2012, it took five years at a final cost of $749.9 million ($1 billion Australian). TSB, a UK bank, changed from a COBOL-based system in 2018 because of a buyout. The bank was unable to trade for days. The migration cost was $454 million. Engineering the actual migration was even more. TSB lost $68 million from financial fraud while its systems were melting down. Customer compensation for the systems being down was more than $172 million. The bank spent $168 million on new staff to deal with 204,000 customer complaints. The CEO resigned. TSB is still trying to fix the damage. It's very easy to tell someone else to switch languages when it's not your ass on the line. But if it IS your ass, there's a whole other look to it. As far as getting new programmers - that is no problem. COBOL is very easy to learn. It is very easy to train people up. And what programmer doesn't know more than one language anyways? It's just one more language.

wudangmonk 5y ago

They should toss it to the Rust community, they'll happily rewrite it in Rust, might not even need to pay them as long as you allow them to always tell everyone they are Rewriting it in Rust.

mariuolo 5y ago
As long as they will also take on the financial risk due to potential errors in their code.

cratermoon 5y ago

Anecdotal data point: I worked, as a consultant, with a team of COBOL programmers that had been sent to some kind of "Java in 21 days" course. The system they were in the process of writing when I came on board used the "float" type to store money. There was a point at which one of the programmers said he ignored the tests on amounts that were failing in reproducible ways because he thought they were wrong. To this day I don't know the full cost of replacing all the uses of float with BigDecimal, but I'm glad one of my fellow consultants had a math and finance background and was able to sort it out. Why did the COBOL folks use float and not know about the problems with IEEE-754 floating point?[1] Because they had been using COBOL, which, because it was purpose-built for business and accounting has fixed-point arithmetic, handles money naturally. 1. https://0.30000000000000004.com/ https://0.30000000000000004.com/

jamesfinlayson 5y ago
Good grief... it's not like IEEE 754 is new by any stretch.
- cratermoon 5y ago
  Yes but if you've spent your career working in a programming language that just does the Right Thing (per business/accounting rules), and you're thrown into a project with a language you don't know and need to do money math, it's not unreasonable to expect, until told otherwise, that 0.1 + 0.2 = 0.3. The COBOL-turned-Java programmers I worked with may not have been the best (nor is Java all that), but the fact that COBOL does money the way we intuitively expect "out of the box" is why it remains in wide use. What other language has a built-in Money type that handles error accumulation and rounding the way accountants expect?