Tim BrayIBM crashes because we’re gonna YOLO a replacement for banking and credit-card back-ends, replacing billions of lines of COBOL with vibe code. Uh…
https://www.techbuzz.ai/articles/ibm-crashes-11-as-anthropic-threatens-cobol-empire
Worik> COBOL systems are so old that any viable alternative becomes immediately attractive.
A tech journalist said that. We're doomed, if we cannot build IT infrastructure that can last for decades.
Good news is we can.
Bad news is there is more profit in new crap than in maintaining the existing infrastructure
Software, generally, socks mostly for that reason. And they are laying off all the computer programmers...
zbrown
mike805@zbrown @worik @timbray Last time they laid off all the COBOL programmers, Y2K happened and they had to go hat in hand to the retired people. A lot of older programmers got a serious upgrade to their retirement.
The fact something lasted decades is good, not bad. If software is going to be infrastructure then it needs to be built like infrastructure.
What are the AI vibe coders going to do when they have to maintain a code base and the AI model that "wrote" it is discontinued? 1/2
@zbrown @worik @timbray Everyone is worried about programmers losing their jobs to AI. From what I am seeing (and I support both kinds of code) there is going to be lots of work for humans fixing what the AIs broke.
One of the basic problems with this technological era is that production is automated and efficient. Repair is still a medieval craft. Look at current generation cars which are nearly unfixable if they get in an accident. AI is making programming like making cars. 2/2
AJ Sadauskas@mike805 @zbrown @worik @timbray Really great points.
And there's a couple of really important points I'd make to the AI boosters and investors who mightn't have a great deal of knowledge about enterprise IT. (By enterprise, I'm talking top-100 corporations, government departments, major research universities, etc.)
First point.
Where you'll often tend to find COBOL is in core business systems. In many cases, these are green screen applications that were custom written for a particular organisation, and were often originally written for something like a VAX system or an IBM 360 mainframe.
They typically store and manage the most critical, business can't operate without it data. They encode the most critical business logic that underlies the company's systems.
In a bank, that might be the system that holds the bank's account and loan balances, and calculate interest payments.
In an electrical utility, that might be the database of all the properties that are connected to the grid, what part of the grid, what equipment is at the substation, etc.
Many of the other systems in the enterprise are either front ends, or integrate with these core systems.
So the clunky web interface the helpdesk staff use or the shiny new mobile app are basically a front end for this system. Your bank's new loan application wizard or your power company's new connections system integrates with it through an API.
Someone just going in there who doesn't know what they're doing and vibe coding on a live, in-production core business system is just a catastrophically stupid idea.
Second point.
You're right. The costs of software are not limited just development and deployment.
I'd break the ongoing costs into five broad buckets.
The first is maintenance. That's everything to just maintain the status quo, such as your regular bug fixes and security patches.
The second is upgrades. The organisation begins offering a whole new category of product or changes its business model. How does its systems evolve to meet those business needs?
The third is catastrophic failures. When shit goes wrong in an unexpected way, how easy and quick is it to troubleshoot and fix?
The fourth is the cost of daily use. This is a biggie that gets overlooked a lot. If your software is buggy and unreliable, and requires a lot of manual workarounds, that puts costs on everyone else in the business.
And the fifth is decommissioning. This one gets overlooked until the time comes to replace the system.
The savings business leaders are often chasing with AI are in development and deployment.
But that's often not where most of the total lifetime costs of the software are.
And there's a couple of really important points I'd make to the AI boosters and investors who mightn't have a great deal of knowledge about enterprise IT. (By enterprise, I'm talking top-100 corporations, government departments, major research universities, etc.)
First point.
Where you'll often tend to find COBOL is in core business systems. In many cases, these are green screen applications that were custom written for a particular organisation, and were often originally written for something like a VAX system or an IBM 360 mainframe.
They typically store and manage the most critical, business can't operate without it data. They encode the most critical business logic that underlies the company's systems.
In a bank, that might be the system that holds the bank's account and loan balances, and calculate interest payments.
In an electrical utility, that might be the database of all the properties that are connected to the grid, what part of the grid, what equipment is at the substation, etc.
Many of the other systems in the enterprise are either front ends, or integrate with these core systems.
So the clunky web interface the helpdesk staff use or the shiny new mobile app are basically a front end for this system. Your bank's new loan application wizard or your power company's new connections system integrates with it through an API.
Someone just going in there who doesn't know what they're doing and vibe coding on a live, in-production core business system is just a catastrophically stupid idea.
Second point.
You're right. The costs of software are not limited just development and deployment.
I'd break the ongoing costs into five broad buckets.
The first is maintenance. That's everything to just maintain the status quo, such as your regular bug fixes and security patches.
The second is upgrades. The organisation begins offering a whole new category of product or changes its business model. How does its systems evolve to meet those business needs?
The third is catastrophic failures. When shit goes wrong in an unexpected way, how easy and quick is it to troubleshoot and fix?
The fourth is the cost of daily use. This is a biggie that gets overlooked a lot. If your software is buggy and unreliable, and requires a lot of manual workarounds, that puts costs on everyone else in the business.
And the fifth is decommissioning. This one gets overlooked until the time comes to replace the system.
The savings business leaders are often chasing with AI are in development and deployment.
But that's often not where most of the total lifetime costs of the software are.
Richard Penner@aj @mike805 @zbrown @worik @timbray
#SoftwareCosts don't end at deployment.
2001: An engineer adopts a French #OpenSource bulk mailer, running on mostly unsecured SMTP. Over the years it's extended ad hoc — eventually managing security group permissions. The company grows; the #software (now at 100× planned #capacity) falls over daily.
2009: After the original engineer leaves, a contractor-turned-hire inherits it. Memory leaks fixed, algorithms rewritten that had pre-cached the universe for "efficiency." Redundancy established and tested. Deployment documented. The upstream package has been rearchitected twice since 2001, and after being pulled off the project twice to restart, the replacement engineer maps all integrations to the new architecture with a proper API — replacing direct database queries. The max supported mailing groups turns out to be tied to filesystem limits: 32k+ groups (now at 300× original capacity thanks to fixing the memory leaks and hourly restarts) each with a directory, capped by hardlink counts on the inode. A campaign encourages responsible use and better security. Archiving aligns with retention policy. And nearly daily, a manager insists someone didn't get their email, so the engineer traces it by SMTP ID.
Then the company moves to Gmail, which won't tolerate internal mailers forging external domains. Data and management migrate to Google Groups with a new front-end preserving the old permission controls. Legacy API users are tracked and urged to migrate before "the end." And the heart of corporate communication for 15+ years is decommissioned.
Every stage has real costs:
• #Maintenance
• #Upgrade
• #CatastrophicFailure
• #DailyOperations
• #Decommissioning