4 ms·

COBOL isn’t falling apart, the systems are exceeding their design limits. “Oh if it were just written in a modern language everything would be fine”. Not true

COBOL isn’t falling apart, the systems are exceeding their design limits. “Oh if it were just written in a modern language everything would be fine”. Not true - we create modern systems every day that would choke and die if they had to scale several orders of magnitude instantly - in fact it happens about weekly when an unsuspecting link hits the HN front page. Also, I would wager 90%+ of software written today is 10-100x more fragile over time than whatever COBOL software is on these machines. What do you think the chances are of those 100 fancifully orchestrated micro-services running 10 abstraction layers up on 3rd party infrastructure are of running at all a decade from now, never mind within their original design constraints. Old doesn’t necessarily mean worse and newer doesn’t necessarily mean better, but that logical foundation is easy to forget in a tech culture so often myopically focused on innovation(tm) and short-term profit or austerity above robustness. The relative rarity of COBOL programmers aside, this is a just an garden variety f* up of keeping legacy systems around too long because they aren’t “broken”. And like technical debt, the money and effort to fix them, despite many warnings and pleas, is called a waste because there is no immediate benefit or profit. Then something like this happens, and everyone forgets the shortsighted management or decision makers that ignored the risk and collected bonuses and praise for saving the Corp/taxpayers money. Those who warned about the debt coming due get nothing except being able to say “I told you so” for a few weeks until the whole thing blows over.

gregjor 7y ago
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.

gregjor 7y ago

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.