"one does not simply rewrite vim" is prior evidence to suggest: no, usually you brake of a rewrite unless you have a very good reason and made much better choices the second time around.
I am a care taker for an elderly parent. This worries me some. What sort of things should I get together if we need to reapply or other documents would we need to show that she has been receiving SSA payments (for 40 years of work)?
They certainly stack, how else would you get to Mars other than with a space-elevator-type-ladder of 10x engineers. Certainly not those failing brittle rockets.
Login to https://www.ssa.gov/ and click the "Your Social Security Statement" link at the top of your homepage to download a PDF or XML file of your earnings by year and total payments to SS and Medicare.
I'd say download both the PDF and the XML. The PDF is easier to read, but the XML has more information.
In particular the XML shows earnings for every year. The PDF shows earnings for several recent years, and then from groups of years before that. I don't know if it is the same groupings for everyone but mine is grouping 1966-1980, 1981-1990, 1991-2000, 2001-2005, then the individual years up to 2024.
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?
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"
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
Grok, make a node.js program to administer and oversee hundreds of millions of dollars in payments to millions of retirees. VERY IMPORTANT: No fraud or DEI.
Someone once asked me how long it would be before I arrived to a meeting (wasn't late) and I told them it could be measured in nanoseconds. Same energy.
Not really surprised, it's the usual mistake of any novice engineer, thinking that rewriting a system they don't like is going to solve all the issues they imagine.
With the teenagers involved in DOGE under Musk it's just going to be hilarious when they inevitably fail. They just never had the experience to actually go through a complete rewrite of something that's been alive for decades... And never bothered to read "The Mythical Man-Month" because of course they are ninja rockstars 100x developers, and lessons from history and experience don't apply to them.
Really sad that their mess will do very real harm to lots of people who depend on this system working...
I don't think this is a case of "Second System Syndrome" I think this is an instance of shock therapy being applied at home. When they fail they can blame woke DEI and just tell everyone they are increasing the limit on 401(k) and IRA contributions so who even needs SS anyways?
> it's just going to be hilarious when they inevitably fail.
I won't be surprised if the "failure" is then twisted as the "success". I see tech projects basking in their success when in reality they just make things harder for everyone. In this specific case, let's see what could go wrong? Someone doesn't get paid their social security — but that's not a bug that's a feature. Govt money saved :).
obviously the entire thing is horrific, but the complete fucking malice of the senior people, starting at trump, who act is if nothing in the world is hard or complicated, and all they have to do is be loud massive cunts and things will work out their (personal, of course - none of them give a fuck about others or indeed "America") way is just absolute poison that will destroy America.
in this particular case, we've actually already seen what happens - "Xtreme Programming" was birthed from the - failed - attempt to re-write the Chrysler payroll system in Smalltalk in the 1990s: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
edit: and that was run by Kent Beck, not the National Union of Racist CS Undergrads that Musk exclusively hires from
The old "The place is clean, why do I need cleaners" line.
I mean, there is a chance that this might work. But I strongly doubt that it would. Given Musk's history of re-writes and deadlines, I suspect that actually its not going to happen.
But on the flip side, if you don't care about complying with the law or caring about users, its probably possible.
Don't get me wrong, the SSA needs some innovation, but innovation, not revolution.
I was being "generous" so that people don't instantly write off the rest of my post, should they be ideologically opposed to seeing what a massive massive risk DOGE pose by fucking with this stuff.
So head-smackingly stupid. But also exactly what you’d expect from a group of inexperienced young developers. What are the odds we'll end up with an 85% AI generated NextJS-powered app that melts down the second it's implemented?
I honestly think their strategy at this point might be to incur so incredibly much in very-real damages on a variety of fronts that the courts are left with the choice of either letting them get away with most of it (so, most folks aren't compensated for the harm they suffered) or forcing the US into abrupt bankruptcy (same outcome for the harmed, but also the US enters a severe depression instantly).
WHEN they screw this up any litigation will be a "witch hunt" and they'll simply refuse to pay any settlement awarded, assuming they allow it to get that far.
Is he going to outsource this to India with data access?
Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
Those weren't Musk's edgelord "DOGE" children, they were people on the highly-effective Obama-created digital tiger team USDS, which team Trump killed and then reanimated as a DOGE-zombie, to avoid having to ask Congress to create a DOGE bureau for him. US "DOGE" Service, instead of Digital, and yes that really is what they changed it to in the EO that did this, I'm not making it up, it was that stupid.
> Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
Oh and last I checked they were claiming he's only working one day a week, to stretch this out effectively indefinitely. They'll probably get away with it.
> Again, 150-year-olds are not collecting social security benefits. That specific age was likely a quirk of COBOL. It doesn’t include a date type, so dates are often coded to a specific reference point—May 20, 1875, the date of an international standards-setting conference held in Paris, known as the Convention du Mètre.
I thought this was wishful thinking / already deboonked?
This part has if you trust Elon as a source. He shared some graphs where there was no spike at 150, and people older than 150. If you trust Elon on this is really up to the reader, but it's a peeve of mine that sources keep reporting the COBOL epoch thing, which was always just a (plausible) theory as fact.
> Again, 150-year-olds are not collecting social security benefits.
This part hasn't. These 150 year olds are simply people whose death hasn't been recorded. They aren't collecting Social Security. In fact social security automatically stops at 115, and the number of Social Security recipients over 100 is within expectations [1]. This if course doesn't not mean there are zero deab people still receiving checks. With any system this size some fraud will exist, the question is how much, and how much does it cost to chase down.
The issue with unrecorded deaths for people over 100 has been known since at least 2015 [2]. In short it hasn't been fixed due to the cost, combined with the risk of incorrectly marking someone dead, which can seriously fuck up your life, not just social security. This whole bruhaha could have been avoided if someone did a 5-minute Google search before Elon/Trump started their theatrics.
It's not like nobody's ever looked into fraud and error rates in social programs.
It's consistently pretty damn low, and when problems have been found, they've usually been addressed.
People think these are full of fraud for the same reason they think foreign aid is some insane double-digit percentage of the budget: because Republicans shove messaging at them through dedicated propaganda outlets literally 24/7 complaining about these things, and have done this for decades, and folks don't bother to check.
a number much lower than the various rates of wage theft that occur/defraud funding of social security by American businesses. Funny which one DOGE is going after first. Seems like Elon should go after businesses fraudulently not funding Social Security as the first priority.
It's almost like his stated reasons for DOGE are a thin pretense...
Elon should never be given the benefit of the doubt on anything at this point given how blatantly and frequently he lies. Anything he says should be ignored and assumed to be false without actual evidence.
I don't know Social Security's data model, but I wouldn't be surprised if it was still legitimately paying out pensions derived from the accounts of people who'd be 150+ if they were still living.
> This if course doesn't not mean there are zero deab people still receiving checks. With any system this size some fraud will exist, the question is how much, and how much does it cost to chase down.
Right, it's an optimization problem. You fight the fraud to the point that it optimizes loss. If it costs $1 million to stop $10 million of fraud, you do it. If it costs $1 billion to stop $10 million of fraud, you let that fraud happen.
As somebody that has worked at the CDC and now works for the NIH, the thing that enrages me about all of this is the gov desperately needs more efficiency. With hiring, compliance, grants, etc. Its very telling that I have heard nothing about the rube goldberg usajobs application system from DOGE.
Instead, we are getting a stupid made-for-TV efficiency, where the leaders refuse to understand technical concepts as braindead simple as a reference date.
I think it's remarkable, that if you look at like immigration, they really play up the emotional aspects of what they're doing, because they're fundamentally not as competent at deportations. Similar to this, they don't have any answers of how to make it really efficient because it's "hard" so instead we get a twitter feed of imagined savings.
It never fails to amaze me how little we learn from the past. I wish I knew if it was unique to software development or all industries suffer from this level of hubris.
IIRC EBay rewrote their backend three times. It was not because the previous version was wrong, but because they were growing and changing, so a new backend was needed anyway to tackle that. They were and are doing fine.
Twitter rewrote their codebase from Ruby on Rails (the endless source of fail whales) to a completely different platform, again due to the huge growth. Technology-wise, they are doing pretty fine.
Facebook rewrote Messenger from a very thick and complex client architecture to an outrageously lightweight and flexible architecture based on eventual consistency / roughly-CRDT approach. FB Messenger is doing very fine.
Never rewrite your codebase without a really good reason. Big wins in performance, maintainability, and ease of development may be good reasons, depending on your situation.
139 comments
[ 4.6 ms ] story [ 179 ms ] thread[1] https://www.ssa.gov/myaccount/statement.html
[2] https://www.ssa.gov/manage-benefits/view-benefit-payment-sch...
[3] https://www.ssa.gov/benefits/retirement/planner/applying5.ht...
Kind of like "not even wrong".
https://news.ycombinator.com/item?id=43505659#43506099
In particular the XML shows earnings for every year. The PDF shows earnings for several recent years, and then from groups of years before that. I don't know if it is the same groupings for everyone but mine is grouping 1966-1980, 1981-1990, 1991-2000, 2001-2005, then the individual years up to 2024.
Which of the unpaid 60+ workhours/week youths that Elon is sending in will stay on the project after shipping 1.0 ?
Rewriting in something where engineers are cheaper and that can use commodity/cloud servers probably looks quite good on paper Vs paying IBM in blood.
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.
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.
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)
It will make the initial launch of healthcare.gov look like a paradise of puppies and flowers.
Let me introduce you to an IBM salesperson who knows you have no option apart from renew those contracts on the mainframe and COBOL consultants :)
https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf
> 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.
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.
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.
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.
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.)
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.
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 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.
https://en.wikipedia.org/wiki/Misclassification_of_employees... https://en.wikipedia.org/wiki/Wage_theft
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.
Millions of millions, even. "The federal government spent $1.35 trillion on Social Security in fiscal year 2023."[0]
[0] https://usafacts.org/articles/how-much-does-the-us-spend-on-...
What can go wrong and with the inspection service all fired, who will check for backdoors
Again these people need to go, and as others said, save everything you have from SSA on paper and if you can PDFs.
*had. Doge will make short work of it.
With the teenagers involved in DOGE under Musk it's just going to be hilarious when they inevitably fail. They just never had the experience to actually go through a complete rewrite of something that's been alive for decades... And never bothered to read "The Mythical Man-Month" because of course they are ninja rockstars 100x developers, and lessons from history and experience don't apply to them.
Really sad that their mess will do very real harm to lots of people who depend on this system working...
I won't be surprised if the "failure" is then twisted as the "success". I see tech projects basking in their success when in reality they just make things harder for everyone. In this specific case, let's see what could go wrong? Someone doesn't get paid their social security — but that's not a bug that's a feature. Govt money saved :).
in this particular case, we've actually already seen what happens - "Xtreme Programming" was birthed from the - failed - attempt to re-write the Chrysler payroll system in Smalltalk in the 1990s: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
edit: and that was run by Kent Beck, not the National Union of Racist CS Undergrads that Musk exclusively hires from
I mean, there is a chance that this might work. But I strongly doubt that it would. Given Musk's history of re-writes and deadlines, I suspect that actually its not going to happen.
But on the flip side, if you don't care about complying with the law or caring about users, its probably possible.
Don't get me wrong, the SSA needs some innovation, but innovation, not revolution.
There really isn't.
Then put it live in alpha
Screw up millions of people
Everyone is a beta-tester with Musk, no matter how dangerous to the product
And didn't just 21 out of 50 "DOGE" employees quit in protest?
https://www.npr.org/2025/02/25/nx-s1-5308095/doge-staff-resi...
Is he going to outsource this to India with data access?
Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
> Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
Oh and last I checked they were claiming he's only working one day a week, to stretch this out effectively indefinitely. They'll probably get away with it.
What can an accounting system possibly do? Keep track of people, how much they're eligible for, and when you paid them last. DONE.
> SSA maintains more than 60 million lines of COBOL today, along with millions more lines of other legacy programming languages.
Months?! I hope they mean days. With ChatGPT and AWS, they'll be rolling! All of those millions of lines of code are clearly doing nothing useful.
I thought this was wishful thinking / already deboonked?
This part has if you trust Elon as a source. He shared some graphs where there was no spike at 150, and people older than 150. If you trust Elon on this is really up to the reader, but it's a peeve of mine that sources keep reporting the COBOL epoch thing, which was always just a (plausible) theory as fact.
> Again, 150-year-olds are not collecting social security benefits.
This part hasn't. These 150 year olds are simply people whose death hasn't been recorded. They aren't collecting Social Security. In fact social security automatically stops at 115, and the number of Social Security recipients over 100 is within expectations [1]. This if course doesn't not mean there are zero deab people still receiving checks. With any system this size some fraud will exist, the question is how much, and how much does it cost to chase down.
The issue with unrecorded deaths for people over 100 has been known since at least 2015 [2]. In short it hasn't been fixed due to the cost, combined with the risk of incorrectly marking someone dead, which can seriously fuck up your life, not just social security. This whole bruhaha could have been avoided if someone did a 5-minute Google search before Elon/Trump started their theatrics.
[1] https://www.newsnationnow.com/business/your-money/people-ove...
[2] https://oig.ssa.gov/assets/uploads/a-06-21-51022.pdf
It's consistently pretty damn low, and when problems have been found, they've usually been addressed.
People think these are full of fraud for the same reason they think foreign aid is some insane double-digit percentage of the budget: because Republicans shove messaging at them through dedicated propaganda outlets literally 24/7 complaining about these things, and have done this for decades, and folks don't bother to check.
https://www.youtube.com/watch?v=06H7J0Wjg98&t=233s
a number much lower than the various rates of wage theft that occur/defraud funding of social security by American businesses. Funny which one DOGE is going after first. Seems like Elon should go after businesses fraudulently not funding Social Security as the first priority.
https://en.wikipedia.org/wiki/Wage_theft
Elon should never be given the benefit of the doubt on anything at this point given how blatantly and frequently he lies. Anything he says should be ignored and assumed to be false without actual evidence.
I don't know Social Security's data model, but I wouldn't be surprised if it was still legitimately paying out pensions derived from the accounts of people who'd be 150+ if they were still living.
Right, it's an optimization problem. You fight the fraud to the point that it optimizes loss. If it costs $1 million to stop $10 million of fraud, you do it. If it costs $1 billion to stop $10 million of fraud, you let that fraud happen.
Instead, we are getting a stupid made-for-TV efficiency, where the leaders refuse to understand technical concepts as braindead simple as a reference date.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month
IIRC EBay rewrote their backend three times. It was not because the previous version was wrong, but because they were growing and changing, so a new backend was needed anyway to tackle that. They were and are doing fine.
Twitter rewrote their codebase from Ruby on Rails (the endless source of fail whales) to a completely different platform, again due to the huge growth. Technology-wise, they are doing pretty fine.
Facebook rewrote Messenger from a very thick and complex client architecture to an outrageously lightweight and flexible architecture based on eventual consistency / roughly-CRDT approach. FB Messenger is doing very fine.
Never rewrite your codebase without a really good reason. Big wins in performance, maintainability, and ease of development may be good reasons, depending on your situation.