11–20 of 66 posts
is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?
Mainframes have been having a moment. Or, perhaps more accurately, certain enterprises are finally waking up to the fact that firing all those mainframers wasn't the best idea for the long-term. The current problem isn't the lack of interest of availability of training; both would be there if it weren't for the fact that enterprises are more interested in having their code written by consulting companies in India tha…
The surge in demand is being driven almost entirely by state unemployment systems. Most of these systems haven't seen a surge in unemployment claims since the 2009 recession and haven't had to change the underlying rules governing eligibility in even longer. Once the systems are patched and/or the surge in new claims subsides, 90% of this sudden demand for "Cobalt programmers" will evaporate. It's one thing for retir…
Whenever you see "urgent need" in headlines it's too late to profit from this crisis. If anything learn COBOL in about 10 years for the next crisis.
Mainframes have been having a moment. Or, perhaps more accurately, certain enterprises are finally waking up to the fact that firing all those mainframers wasn't the best idea for the long-term. The current problem isn't the lack of interest of availability of training; both would be there if it weren't for the fact that enterprises are more interested in having their code written by consulting companies in India tha…
It is not only lay offs it is also retirements. And the pressure is mounting with baby boomers gone soon. I was once in a discussion taking over the maintenance of a system and the picture was grim. The crew running the system was so thin it was hard to imagine them having the time handing it over. Besides they barely understood all the details as the system had been build by people 30 years ago all gone a long time…
When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...
is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?
Re-writing that, is going to be a nightmare, as you've got no spec. to work from and mistakes may not show up immediately (think monthly or annual payment processes)
It's a very high risk endevour with little immediate reward for the team doing it. If it goes perfectly, no-one notices, if it goes badly it could seriously impact your whole company.
Earlier quoted context omitted.
Whenever you see "urgent need" in headlines it's too late to profit from this crisis. If anything learn COBOL in about 10 years for the next crisis.
Maybe the 2038 problem?
Indeed, what happens to those already deployed legacy systems and programs are another story.
is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?
It has been done many times, sometimes successfully. Other times it ends up costing hundreds of millions over budget before the effort is abandoned and there is nothing to show for it.
Once technology is entrenched, it becomes self-sufficient and very, very difficult to replace. I remember when mainframe/COBOL apps were being re-written for the client/server era, often using tools like Tuxedo/c++ for the backend and Visual Basic for the front-end. Where are those re-writes now? (Probably replaced a couple of times again, where the COBOL-remainers are still in place.)
I think the days of higher-paying COBOL gigs are still ahead of us. When the greybeards actually go away, there will be a strong need to fill.
I used to work at an environmental law firm in downtown Manhattan and accounting and other core financial systems were running on a VAX OpenVMS mainframe, and the document creation and storage was on PCs over a Token Ring, Banyan VINES network. The DOD was using VINES at the time. Memories of playing DOOM in 1994 downloaded from an FTP server somewhere while working the night shift to make backups on huge tape cartri…
VAX's were minicomputers, not mainframes.
It's amusing to look up "mainframe" on wikipedia and see what appears to be compact server racks. Shouldn't a mainframe take up a room, or even a whole floor?
COBOL is living proof of the power of incumbency. Once technology is entrenched, it becomes self-sufficient and very, very difficult to replace. I remember when mainframe/COBOL apps were being re-written for the client/server era, often using tools like Tuxedo/c++ for the backend and Visual Basic for the front-end. Where are those re-writes now? (Probably replaced a couple of times again, where the COBOL-remainers ar…