I know that the AI that they're going to try to do this with is going to choke on the COBOL side of things a bit, but I have to wonder, what's the target language?
If they were refactoring /cleaning up the code and porting to a modern platform - then yeah, that would be good for the future. But also a massive effort and well beyond anything that someone can parachute in and complete in weeks or months.
If it's an automated transformation from COBOL to say Java, then why? Any machine translated code is not going to be as clean as the source, which itself is probably not that clean if it is typical public sector code that has been mogrified repeatedly over the years to meet changing legislative needs.
There's no obvious reason why a machine translation to Java should be any more reliable than the original COBOL. The only obvious benefit is opening up to a greater number of coders who could make changes. But at the expense of losing the skills of the existing COBOL maintainers. My guess is it would be a wash.
It's less about COBOL and more about the culture that disallows any changes. Because everything is highly regulated and any change must have extensive testing, it's almost impossible to change anything about the original COBOL. Instead, modern systems like online banking are grafted on top as wrappers. If you think this cruft cannot possibly be more reliable than just rewriting the damn thing - you'd be right. And this is why countries that got computers into banks decades after the US are now running circles around the antedeluvian US systems.
The only way out is through and someone has to rip off all these bandaids. And while one is at is, might as well write this in a language known by more than a dozen overpaid graybeards.
Do you have any evidence to back up your claim that newer banks are running circles around US Banking systems? And what does that have to with Social Security?
Yeah, and you can get the same evidence firsthand. Experiencing a banking app literally anywhere but North America ought to do it.
What does it have to do with Social Security? It's the same kind of culture that worships lack of change over everything else, and as a result it is bloated and slow.
My banking app works just fine. Social security payments are very reliable and on-time. Social Security service is declining because of cuts. People are having harder times getting through and setting up appointments. But that's the plan, lie about massive fraud and make the department run poorly so they can start privatizing it.
If they were refactoring /cleaning up the code and porting to a modern platform - then yeah, that would be good for the future. But also a massive effort and well beyond anything that someone can parachute in and complete in weeks or months.
If it's an automated transformation from COBOL to say Java, then why? Any machine translated code is not going to be as clean as the source, which itself is probably not that clean if it is typical public sector code that has been mogrified repeatedly over the years to meet changing legislative needs.
There's no obvious reason why a machine translation to Java should be any more reliable than the original COBOL. The only obvious benefit is opening up to a greater number of coders who could make changes. But at the expense of losing the skills of the existing COBOL maintainers. My guess is it would be a wash.