As someone who used to work for a Mainframe software vendor I'm tired of COBOL being considered "legacy" and bad. I didn't do much COBOL programming, but IBM is still releasing new compilers and new versions of z/OS for the Mainframe. Just because a language is old doesn't mean it's useless and worth rewriting. Instead of having COBOL be the boogeyman explain what the issues are. Is the system stuck on old COBOL versions do to lack of funding for upgrades, incompetence when it comes to long term maintenance plans, technical issues that make it impossible to move forward with new COBOL versions and would require a rewrite, etc. Are we going to see stories like this in 20 years about some company thinking they should rewrite the Linux Kernel in some new language and throw away all the C code that's been running for decades?
So goes almost every project that wants to rewrite a giant legacy system from scratch. In reality the number of developer hours will massively eclipse the price you'd have paid those hard to find COBOL engineers.
But doing that would require the DOGE folks to admit that they don't actually know everything and need to defer to someone with more knowledge. So it can't possibly be allowed.
This was probably kicked off by someone with power seeing how much IBM were charging for support/consultants etc. "Whaaaa? IBM want how much?"
On the other hand while I think it is a bit of a stupid idea to migrate off/rewrite for no reason other than "fuck you IBM", there probably comes a time when it does make sense to migrate - there are often hallmarks of this in old legacy systems where you need to do a LOT of work just to keep things running.
Typical examples are: really hard to recruit/retain people who know the technology, difficult to change things where the use-case does something the original designers did not anticipate, decades of tech-debt that makes people scared to change anything, endless patching of security fixes, lots of "glue-work" trying to interface the legacy systems with more modern things (think database drivers, automation tooling etc etc).
If it is hard to maintain a legacy system today, its going to be even harder in 10 or 20 years. "If it aint broke don't fix it" is valid, but in IT systems (with endless security vulns, endless changes to data legislation and sovereignty controls etc) you cant stand-still and leave things alone if it is a connected system dealing with people's personal data/finances/health/etc.
Somewhere sooner or later you're going to need to pull the trigger and sustain your business by investing in new technology rather than pouring more and more and more money into keeping a legacy system that is no longer fit for purpose. It will hurt sure, but sometimes you have to do it. Just do it carefully and in a realistic way (timelines, testing, slow-migration path etc)
Oh, replacing a legacy system can make sense in a dozen different ways. But you do it carefully, replacing piece by piece and verifying that everything still works. Replacing the whole thing in a couple of months? Doomed. Absolutely doomed.
I can’t say I’ve worked in the COBOL space but it certainly seems like it would be difficult to hire people focused on less transferable tech knowledge. Specialization comes with risk of being phased out and left with your thumb in the wind.
Generally people choose technology that’s going to maximize their prospects in terms of employment. Maybe that is specializing in COBOL, systems and tech around it, and higher level abstractions that inevitably come along. For me that seems risky in terms of time investment, even more so in todays market, but I could be very wrong.
> Yet, we place extraordinary demands on an installed base of technology that is increasingly showing its age. Most of our core systems are over 30 years old and some embedded software components are older. Over the years, newer technologies have been integrated with these legacy systems without a fundamental redesign of the system and enterprise environment within which it operates. Today, the cost of operating in this legacy environment is expensive. Front- line SSA employees are finding these systems increasingly difficult to use, and members of the public are not getting the self-service opportunities they have come to expect based on their experience with commercial enterprises. Furthermore, systems engineers with legacy system expertise are retiring from SSA at an increasing rate. Replacing them with similarly skilled staff is also increasingly difficult in the current job market.
Then start hiring people at decent pay and provide actual training. This is completely anecdotal but I feel like Mainframe doesn't pay great. I was lucky that i did a lot of work with Java on the mainframe so was able to switch to a non mainframe company and get a significant salary bump. I've also had virtually no interest from recruiters based on my Mainframe experience. I'm not sure if that's because I don't have it front and center on LinkedIn, or if there just isn't a lot of hiring in the Mainframe space? The lack of interest in my Mainframe experience was a thing in 2021 and 2022 as well so I don't think it's related to the current market.
Because mainframe is "legacy" and also "dusty" technology it won't show in magazines as much as the hype du jour - nosql, frontend wonders, you name it. So yes it will be paid less by default. Also the fact that mostly old folks are maintaining those systems quietly is neither helping their image nor pushing their salaries.
Yeah, I wonder how much tooling their is around the existing app and api's. I remember being on this team managing users in this kinda archaic way using scripts, but the scripts we're really effective, so someone came in and rewrote the whole thing to use LDAP, and like sure it was technically the right choice, but it added like 6 hours per week of overhead because the tooling wasn't there, and, there were no real described tangible benefits other than "lol, bash scripts"
I also find it funny that COBOL is treated as the boogeyman. It's just a language. Any programmer by profession should be capable of learning a language decently in a month, and better within the year.
So when people say "all the COBOL programmers are retiring!", they're completely missing the problem. The language isn't the problem.
The problem is the design of the software written in COBOL, z/OS itself, and the operators that defend its design. The software has so much dark matter due to tech debt, partially due to age, partially due to vintage. z/OS has tech debt, due to designs for a different era being carried forward. Manual processes that should have safety guards and technical limitations abound.
But that's not to say DOGE should be trying to rewrite this stuff. Not on their schedule and not with their staff. Because it will create bugs. The same reason this software persists.
Much lower hanging fruit than a re-write project would be to go after wage theft and businesses fraudulently not paying into Social Security such as via mis-classification. Not sure why Doge doesn't prioritize that largest offenders/perpetrators of fraud against Social Security, I.E. American business that routinely fraudulently fail to follow the law. Misclassification/taking peoples wages (prevent social security being pay on those taken funds) are larger than the agreed sub 1% of Social Security payments that are fraud.
cobol is trivial to learn. the problem is that the core of old systems were written even before 'Structured Programming' and anything like reviewing and enforcing design standards. there is alot of 60 year old, currently running 'mission critical' cobol, some of it is inscrutable and unmaintainable, while some of it is so simple and elegant that it'd be a great way to teach a 10 year old about programming.
COBOL is also missing most of the QOL aspects of modern languages.
A COBOL system is closer to a bunch of shell scripts coordinated by a master script than anything we might today think of as modular and componentized.
I won't go so far as to say "every variable is global", but it's darn close.
This misses the point of why COBOL is legacy and bad.
Using a language with no real community support and a very small available skilled workforce has massive negative effects on cost and productivity (i.e., the ability to deliver changes at reasonable cost, in reasonable timeframes, and with reasonable success).
You don't want to have something that people could be taught to operate, you want something where skill is a commodity and competition is sprawling. COBOL fails on these parameters, and therefore it is "legacy and bad".
You can replace COBOL in the above with any language having insufficient contemporary adoption.
COBOL engineers are about the lowest on the pay grade and steadily deliver (when they are involved). Peanuts compared to any fancy consultant invited to draw cloud architectures with unrealistic expectations or timeframes. So this workforce cost argument does not hold water. However, licenses are very expensive indeed, which is why there are migration pathways for COBOL-on-other-platforms. But a migration is much less sexy than a rewrite (AI supported) so there.
The general consensus around here has always been that you can get paid whatever you want if you're willing to code COBOL by being a specialist consultant. This holds true for any legacy system, whether it's a factory control system, a legacy programming language, an ancient piece of hardware or whatever.
That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs.
"Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.
IBM puts the number of COBOL devs at around 2 million, others around 1 million. Full-time experienced people is placed at around 200,000.
Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.
You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers.
Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't.
Compare language or language, or component to component.
(Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
Yes. I take numbers from IBM as true. I'm not a conspiracy theorist. As I'm not a conspiracy theorist online numbers definitely give close enough for an online discussion. We aren't talking about legalities of a law, we are talking general conversational understanding.
Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers.
I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.
> Compare use case to use case, not language to language.
Then you are comparing "bank account interest and debt systems" to "embedded drivers".
Or "tax systems" to "embedded drivers".
Or "insurance policy engines" to "embedded drivers", etc.
COBOL is not a use-case, and all of the above could be done in any language. If we are discussing the qualities, ease of training , workforce availability and overall viability of COBOL, it is against the qualities, ease of training, workforce availability and overall viability of other languages.
> We can train up COBOL developers MORE easily than embedded driver devs.
And we can train up web devs more easily than embedded driver devs.
Your argument makes no sense, as it is a false dichotomy. It also entirely misses the point that I stated earlier, that a company does not want to be able to train developers, they already trained developers to be in abundance in the market.
> I've know embedded driver developers and y you're completely wrong
I work in embedded (nowadays audio and display tech), and with driver development (to make said embedded devices useful, previously for high performance datacenter network equipment), and you're completely wrong.
Not to mention delusional regarding COBOL to the point of being a suspect of IBM employment. The only still relevant quality of COBOL is that it does not self combust so we can take our time with replacing it with something contemporary and financially sensible.
You're not really contradicting me you're actually underlining what I was getting at.
You claimed the COBOL ecosystem is too small to depend on. I pointed out that the embedded driver ecosystem is similarly small, yet we rely on it all the time. That’s a valid comparison as both involve small pools of specialists, niche tooling, long lived systems, and a steep learning curve. When I say “ecosystem,” that’s what I mean, not “tax systems” or “insurance policy engines,” which aren’t standalone developer ecosystems in the same way. Equating those with actual engineering ecosystems like COBOL or embedded drivers doesn’t really hold up.
Since you say you work in embedded then you should be well aware that embedded driver developers form a highly specialized subset, often with deep platform specific expertise and niche tooling. It is, in fact, easier to train a developer to work on enterprise COBOL systems than to become effective in low-level driver development. That’s not controversial it’s backed by experience across industries.
As for suggesting I must work for IBM because I don’t agree with your framing that’s not a serious argument. It’s not grounded in facts or reason, and doesn’t contribute anything meaningful to the discussion.
If you’re interested in debating the actual points, I’m happy to continue. If not, I’ll leave it here.
Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.
Throw away the codebase: no, until you have a well-working, battle-tested replacement. I mean, yes, it's possible to do, and you can even run e.g. Java under z/OS on the same in-house mainframe hardware because you can't trust the public cloud. But you still have to do the massive work of reverse-engineering the ancient, scantly documented Cobol codebase, write a modern replacement, cover a ton of corner cases, run in in prod as a shadow that does all the same work, and comparing the results with the load-bearing Cobol codebase, and switch over very carefully.
Depending on the size of your codebase, the complexity of your processes, the strength of your need for change, and the quality of your engineering org, the above may be a very costly process. Few managers are comfortable to approve such a large cost without a very clear return on this investment. Hence we'll see Cobol running for a few decades more.
