almost all major financial institutions, utilities, gov't agencies, etc still rely heavily on COBOL today. If it ain't (extremely) broken, don't fix it?
COBOL developers are literally dying out which has made for a competitive market for remaining talent. I've heard of some large consultants charging over $500/hr to their clients for a COBOL developer!
I feel like every time COBOL is mentioned we get these stories about crazy high comp for COBOL developers, but anecdotally my aunt worked on COBOL projects in the mid 2010s and was paid a much more modest 45 $/hr. Good money for small town middle America where she lives, but nowhere close to what a decent JS dev can get.
There's also the difference between what a consulting company bills for the COBOL developer and what they pay the developer. Not every consultant is the captain of their own ship.
My first job after college was a software shop organized in a "services" model, where clients would have to sponsor teams to do feature dev or support beyond initial onboarding. It's been a long time and my memory is hazy, but as I recall I was expected to bill ~40 hours a week to clients and if I only worked 40 hours that week (being OT exempt, this was always the goal), my hourly pay came out to between 10-20% of what the company billed the client.
So $500/hr on the bill and $45/hr on the paycheck both manage to sound plausible, even at the same company.
Similar experience with a friend of mine. I feel like these high salaries only apply to people who habe worked at one of these companies for a looong time.
In COBOL implementations, it's generally not just knowledge of the language that makes you valuable, it's knowledge of the implementation at that particular organization. I'm not a COBOL dev myself, but I work with them, and part of the challenge is that everything is so uber-customized, tightly coupled, and there's 40+ years of undocumented business logic buried in the code.
It's like the old joke about the engineer being asked for an itemized bill:
"Chalk mark: $1. Knowing where to put it: $4,999."
I work for a major utility and they used to run everything on mainframe and cobol but that went away long before I started programming. My coworker is nearing retirement, around 30 years here, and he started on cobol and worked on transitioning off. He has some really fun stories but my point being, the tales of cobol prevalence are very exaggerated. Maybe some parts of finance are still using it, not my area.
I think the moat that COBOL developers have is not just their knowledge of the language, but knowledge of the mainframe programming and operating environment. Its just so alien to developers familiar with Windows/Linux, and there is really no way to get experience with the environment that I know of, other than to be employed doing it.
But yeah that stuff is never going away as far as I can tell. Its just too risky to rewrite those core systems and many a boondoggle has tried and failed.
About a decade ago I looked into moving some COBOL components off-mainframe (either as COBOL-on-Linux or a rewrite into Java, which itself is really COBOL Mk II at this point), and your point about the operating environment is one of the key elements, but not all of it; there's also the fact that the first big shift to automation, via mainframe assembler and COBOL, is when companies sacked a lot of the folks who knew how and why the pre-automation processes worked - that knowledge exists in the mainframe code and the heads of the people who work(ed) on it, and nowhere else. A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
The third is that COBOL is only the tip of the iceberg. As soon as I spent time learning about the code I was being asked to look at, you get into decades of evolving programming practises. Modern COBOL is multithreaded, probably uses DB2 and relational datamodels. COBOL from thirty years ago is probably single-threaded, only runs right on high-clocked single-execution models, cuts down to hand-written s390 assembler regularly, and uses VSAM files with non-relational data. Older code still will be sharing data simply by banging it into memory regions for other code to read out of, because that's how you got performance back in the day.
Trying to identify how you'd pull a function out of that and move it off is somewhere between extremely difficult and impossible. It's usually so complicated and expensive it's easier to try and hire people who want to apprentice as mainframe programmers and keep the current codebase running.
> A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
And that's why so many neo-banks/fintechs are eating the lunch of the established banks left and right, same for insurance. The "old guard" is unwilling to pay the costs of not just upgrading off of mainframes (aka the rewrite work itself)... but of changing their processes. That is where the real cost is at:
When you have 213.000 employees like BoA has and everyone needs to have at least 10 hours of training and 2 weeks until they're familiar with the new system enough to be fully productive, that's like 2 million man-hours just for training and 16 million hours in lost productivity, so assuming $50/h average salary it's around 900 million dollars in cost. Unfortunately for the dinosaurs, the demands of both the customers and (at least in Europe) regulatory agencies especially for real-time financial transfers just push the old mainframe stuff to limits, while at the same time banks don't want to cede more and more of that cake to Paypal and friends that charge quite the sum for (effectively) lending money to banks.
In contrast, all the newcomers start with greenfield IT, most likely some sort of more-or-less standard SAP. That one actually supports running unit and integration tests automatically, drastically reducing the chance of fuck-ups that might draw in unwanted regulatory attention.
BOA doesn't train the vast, vast majority of its workforce on mainframe systems these days. No one working in a branch or call center is looking at green screens anymore. The mainframe systems are simply used as back-ends connected through web services (yes, even in CICS!) or MQ Series and the like to web GUIs.
Source: worked there for many years, and built some of those integration systems.
Eh, I think the tech stack is less important than the legal and regulatory structure.
Most fintechs aren't banks and partner with a Real Bank™ to provide the actual bank accounts. Fintechs are under much less regulatory scrutiny (for now—that may be changing with recent, high-profile screwups) and can move with much more freedom regardless of the tech stack they've chosen.
Can't we just apply a bunch of correctness preserving translations towards a modern PL, perhaps aided by an LLM to keep the source as human readable as possible, while (I'm stressing this) preserving correctness?
You should take a look at my company. Heirloom Computing. Heirloom.cc We have migrated many mainframe application and millions of lines of cobol and pl1 into Java and deployed it into production on prem and into the cloud.
But is the conversion maintainable by a human? I’ve seen Fortran to C translators that end up encoding state transition machines that are impossible to read.
That seems like a myth to me. I actually looked up COBOL salaries and they were a bit higher (like 20%) but definitely not enough to make them tempting.
AmpUp | Remote/Hybrid – Santa Clara, Boston | Electric Vehicles, Software, Climate Tech, Utilities | https://ampup.io
AmpUp is the leading electric vehicle (EV) charging operating system that enables drivers, hosts, and fleets to charge stress-free. Our technology makes it easy for businesses and property owners to manage multiple charge stations and locations on one platform. We enable our customers to achieve their electrification goals faster and easier than they imagined possible.
We are seeking an experienced and motivated Government & Utility Analyst to support sales across US & Canada. The analyst will be responsible for identifying, responding, and winning RFPs as well as support new business opportunities within the electric vehicle charging market.
Please email 'gnu@ampup.io' with your resume and cover letter if interested.
“Installing, wiring, and connecting the pieces of a traditional post-and-frame switchgear takes about 50 hours of on-site electrical labor,” Seitz said. “And that doesn’t take into consideration the time, costs, and difficulty of sourcing components from various manufacturers and supply houses.” Traditional switchgear is composed of electrical panels that are tasked with receiving, distributing, and protecting the site’s power. The components include a power disconnect panel, a current transformer (CT) cabinet, utility meter, distribution panels, and a transformer.
“Just measuring, cutting and assembling the typical post-and-frame structure for these panels takes two days,” Seitz said. “That’s before the electrician even begins handling the electrical components.” Next steps include:
Removing all dead fronts from tubs panels
Mounting the panels, cabinets and enclosures
Removing all the conduit knockouts
Installing conduit fittings and conduit
Mounting all breakers and internal equipment to bus bars
Running wire through conduit
Terminating all wires
Making the external field wiring conduit connections
sadly utilities are both run inefficiently AND slow to adopt new technology. If you cut their budgets they still print money and come out profitable. Since many utilities are beholden to their shareholders, there are incentivized to NOT upgrade and sweat assets until end of life...
Although critical to safety, much of the clean energy transition is in the hands of utilities to move quicker. With a 50+ year track record of not doing so I'm curious what government and/or private sector can do to remove the utilities involvement or red tape.
Level 2 chargers have been easier to install but the DC Fast Chargers backed by big IRA bucks will be a tough slog. Utility transmission line drops (12 months), battery storage, installation/engineering (3 months) trenching, concrete pouring, permitting (3-6 months), union labor, DOT involvement (6 months). The day is soon approaching where we have far more EVs than charge stations ready to install.
non-compete rule does not apply to:
"Executives, defined as "any person who holds the office of chief executive officer, president, chief administrative officer, chief operating officer, chief financial officer, chief information officer, chief legal officer, chief human resources officer or chief corporate development officer, or holds any other chief executive position."
lol - cofounder is fine, as well as board member, head of sales... really whatever you want your title to be
As far as company rehulations are concerned, these titles have specific meanings, powers and liabilities. You can call the positions anything like Tesla does, but as far as regulators are concerned your company will still need to define some of these roles/accountabilities in specific people.
AmpUp is an electric vehicle (EV) software company and network provider that enables drivers, hosts, and fleets to charge stress-free. We are hiring a gov't and utility intern to assist with bids, RFPs, and grant writing, as well as other business development activity.
Job Requirements & Responsibilities:
* Undergraduate degree minimum, Graduate degree or candidate preferred
* 2-5 years of experience in utility and/or government relations
* Experience with utility, clean energy, and/or government bids a plus
* Strong technical writing and communication skills
* Experience in grant writing and program research
* Interest and passion for electric vehicles and/or clean energy
* Ability to work flexible hours to meet RFP and bid deadlines
Interested candidates should send their resume and a short introduction to matt@ampup.io
Venture University - just an awesome way to immerse yourself into how venture capital works and what it takes for both the startup and investor to achieve their goals.
So much of our future falls in the hands of companies and investors funding them, so knowing how all of this works is crucial to understanding why and when company's make huge decisions that impact us.
COBOL developers are literally dying out which has made for a competitive market for remaining talent. I've heard of some large consultants charging over $500/hr to their clients for a COBOL developer!
reply