3 ms·

I agree with what you wrote, this is not a problem with the COBOL language, except in the narrow sense that it’s not taught anymore and probably 95% of programm

I agree with what you wrote, this is not a problem with the COBOL language, except in the narrow sense that it’s not taught anymore and probably 95% of programmers working today have never seen COBOL. A professional programmer with some experience can learn COBOL in a few weeks. It’s not Linear A. The cost of fixing technical debt has to outweigh the cost and risks of replacing legacy systems. Most ground-up rewrites fail, and that’s even more of a problem in the government sector. A working system with problems is still better than an imaginary system that will probably never go live. Google IRS, California DMV, Oregon utilities, etc. etc. for examples of how these rewrites actually work out.

theincredulousk 7y ago
Yes I do remember reading the one - maybe it was Google IRS - that they tried replacing cobol with Java. Maybe in some cases they just need a new IBM mainframe instead of re-written software.
- thu2111 7y ago
  Emulating mainframes isn't an uncommon approach. But, switching to something like Java would be far better. COBOL on mainframes has nothing to recommend it. There are good reasons nobody chooses to write new systems that way. For one, it's a single vendor tech in which that vendor is a huge firm in terminal decline and thus highly incentivised to squeeze customers financially as hard as possible; government IT spending is already wasteful without propping up the IBM share price. There are few paths forward to improve such systems. Beyond the lack of skilled personnel, there's no real open source community or any community producing libraries or integrations. The problems with these sorts of rewrites are that non-technical managers don't really understand the concept of tech debt until it's way too late and you have a situation like this one. There's no sense that constant improvement should be expected, like what you find in the tech industry, indeed they usually take pride in avoiding projects that are "technology for technologies sake". And that sounds very reasonable, right up until you discover people have basic expectations that you can't fulfil in any plausibly fast manner, or everyone who understands your system has retired and died. So to justify any replatforming or upgrade project, it has to be done via promising lots of new features as part of the rewrite and that screws with the sequencing. Now it's not a tech upgrade project but rather a total upgrade of many different things simultaneously, including often rigid business processes.

theincredulousk 7y ago

Yes I do remember reading the one - maybe it was Google IRS - that they tried replacing cobol with Java. Maybe in some cases they just need a new IBM mainframe instead of re-written software.

thu2111 7y ago
Emulating mainframes isn't an uncommon approach. But, switching to something like Java would be far better. COBOL on mainframes has nothing to recommend it. There are good reasons nobody chooses to write new systems that way. For one, it's a single vendor tech in which that vendor is a huge firm in terminal decline and thus highly incentivised to squeeze customers financially as hard as possible; government IT spending is already wasteful without propping up the IBM share price. There are few paths forward to improve such systems. Beyond the lack of skilled personnel, there's no real open source community or any community producing libraries or integrations. The problems with these sorts of rewrites are that non-technical managers don't really understand the concept of tech debt until it's way too late and you have a situation like this one. There's no sense that constant improvement should be expected, like what you find in the tech industry, indeed they usually take pride in avoiding projects that are "technology for technologies sake". And that sounds very reasonable, right up until you discover people have basic expectations that you can't fulfil in any plausibly fast manner, or everyone who understands your system has retired and died. So to justify any replatforming or upgrade project, it has to be done via promising lots of new features as part of the rewrite and that screws with the sequencing. Now it's not a tech upgrade project but rather a total upgrade of many different things simultaneously, including often rigid business processes.