4 ms·

I know of an insurance company that has tried 3-4 times at a cost probably in the hundreds of millions to switch off COBOL. The simple fact is that they've spe

by hajile 4y ago

I know of an insurance company that has tried 3-4 times at a cost probably in the hundreds of millions to switch off COBOL. The simple fact is that they've spent tons of time slowly coding in hundreds of thousands of little, undocumented edge cases all over the place. The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there.

charcircuit 4y ago
>The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there. Is it not possible to find a safe subset of cases that can be handled by a new codebase. You use shadow testing to help prove the rewrite handles the cases the same as the old implementation and then grow that subset until it encompasses the whole thing. As the old implementation is used less and less you can run it on a smaller computer and have to maintain it less.
- hajile 4y ago
  It takes years or decades to do the swap. You’ll have both teams working in parallel all that time which costs the company a TON of money. This process also outlasts aging managers. Chances are that leadership will shift at least once and decide it’s taking too long So they kill the replacement, switch languages and/or teams, and try yet again.
derefr 4y ago
It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64 https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL. I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!
- Nextgrid 4y ago
  I'm not sure this would help - COBOL itself is already fairly readable. The problem is that a program doesn't actually contain a full description of the business problem - it only contains what's necessary for the machine to solve the business problem. For example, the system may never be designed to process check deposits on a Sunday (and a lot of date-related calculations will go wrong if you tried to), but guarding against that is accomplished by the "real world" - there's nobody there to file in check deposit requests on those days. Yet, there's nothing explicit in the code about preventing check deposits on a Sunday, so your hypothetical decompiler will have no way to infer that without outside knowledge. What you need is a hypothetical magical decompiler that given a binary or source code as input, will spit out the actual business problem and all the edge-cases it's meant to solve. AI might eventually get us very close to that, but ultimately it'll still be a guessing game.
  - derefr 4y ago
    It sounds like you're increasing the scope of the problem relative to what it needs to be. (And you're not alone: that's seemingly what every bigcorp who tries to do this does, and that's why they all fail.) AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure. If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL. An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting. I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.
Nextgrid 4y ago
It's often worth looking at the business problem itself and see if it's possible to simplify it as to reduce the amount of edge-cases that need to be migrated. If you look at a typical legacy bank you'll see dozens of different credit cards with minor differences such as one charging fees for foreign transactions, etc. All of those are edge-cases that must be kept in code. They presumably do this for market segmentation reasons, however if you account for the cost of 1) maintaining the old COBOL/mainframe system (as it's the only thing that's proven to successfully run those products) or 2) successfully moving all that business logic & edge-cases to a modern system, it could emerge that maintaining those different products costs more to operate/maintain that what it brings in terms of revenue from the market segmentation approach, and they're better off simplifying their product line. This also translates to other areas of the business - less support overhead, etc. The other problem with ordering (and delivering) a successful migration is that a lot of people's jobs in those legacy companies rely on the tech being ancient and would be obsoleted should the tech get better, so there's a lot of internal pushback against this. A lot of people may not actually want the migration to succeed, or at least not to anything actually good as that would put paper-pushers out of a job. The only way IMO to successfully deliver this as a large company is if the top brass effectively sets up a brand new subsidiary, gives it a budget and a task to make a product competitive with what the parent company offers, and when it's ready they can just move off their customers to that new product operated by the subsidiary. Rinse and repeat until no more legacy tech remains. The fact that it's a completely separate company means it remains lean and doesn't have to be fighting against deadweight that sabotages any modernisation attempts to protect their own jobs.
- mywittyname 4y ago
  A lot (most? all?) of these "edge cases" end up handling regulatory or other forms of compliance, which came into effect after the initial software design. There might have been 10 people across as many teams who discussed, designed and vetted a one-line code change. It's not so easy to "simplify" out features which are legal requirements.

by hajile 4y ago

charcircuit 4y ago

>The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there. Is it not possible to find a safe subset of cases that can be handled by a new codebase. You use shadow testing to help prove the rewrite handles the cases the same as the old implementation and then grow that subset until it encompasses the whole thing. As the old implementation is used less and less you can run it on a smaller computer and have to maintain it less.

hajile 4y ago
It takes years or decades to do the swap. You’ll have both teams working in parallel all that time which costs the company a TON of money. This process also outlasts aging managers. Chances are that leadership will shift at least once and decide it’s taking too long So they kill the replacement, switch languages and/or teams, and try yet again.

derefr 4y ago

It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64 https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL. I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!

Nextgrid 4y ago
I'm not sure this would help - COBOL itself is already fairly readable. The problem is that a program doesn't actually contain a full description of the business problem - it only contains what's necessary for the machine to solve the business problem. For example, the system may never be designed to process check deposits on a Sunday (and a lot of date-related calculations will go wrong if you tried to), but guarding against that is accomplished by the "real world" - there's nobody there to file in check deposit requests on those days. Yet, there's nothing explicit in the code about preventing check deposits on a Sunday, so your hypothetical decompiler will have no way to infer that without outside knowledge. What you need is a hypothetical magical decompiler that given a binary or source code as input, will spit out the actual business problem and all the edge-cases it's meant to solve. AI might eventually get us very close to that, but ultimately it'll still be a guessing game.
- derefr 4y ago
  It sounds like you're increasing the scope of the problem relative to what it needs to be. (And you're not alone: that's seemingly what every bigcorp who tries to do this does, and that's why they all fail.) AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure. If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL. An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting. I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.

Nextgrid 4y ago

It's often worth looking at the business problem itself and see if it's possible to simplify it as to reduce the amount of edge-cases that need to be migrated. If you look at a typical legacy bank you'll see dozens of different credit cards with minor differences such as one charging fees for foreign transactions, etc. All of those are edge-cases that must be kept in code. They presumably do this for market segmentation reasons, however if you account for the cost of 1) maintaining the old COBOL/mainframe system (as it's the only thing that's proven to successfully run those products) or 2) successfully moving all that business logic & edge-cases to a modern system, it could emerge that maintaining those different products costs more to operate/maintain that what it brings in terms of revenue from the market segmentation approach, and they're better off simplifying their product line. This also translates to other areas of the business - less support overhead, etc. The other problem with ordering (and delivering) a successful migration is that a lot of people's jobs in those legacy companies rely on the tech being ancient and would be obsoleted should the tech get better, so there's a lot of internal pushback against this. A lot of people may not actually want the migration to succeed, or at least not to anything actually good as that would put paper-pushers out of a job. The only way IMO to successfully deliver this as a large company is if the top brass effectively sets up a brand new subsidiary, gives it a budget and a task to make a product competitive with what the parent company offers, and when it's ready they can just move off their customers to that new product operated by the subsidiary. Rinse and repeat until no more legacy tech remains. The fact that it's a completely separate company means it remains lean and doesn't have to be fighting against deadweight that sabotages any modernisation attempts to protect their own jobs.

mywittyname 4y ago
A lot (most? all?) of these "edge cases" end up handling regulatory or other forms of compliance, which came into effect after the initial software design. There might have been 10 people across as many teams who discussed, designed and vetted a one-line code change. It's not so easy to "simplify" out features which are legal requirements.