Post

For people outside the industry, it may not be common knowledge, but one of the most famous bits of technical writing of all time, was Joel Spolsky saying that you should *never* rewrite an entire code base — 25 years ago. www.joelonsoftware.com/2000/04/06/t...

joelonsoftware.comThings You Should Never Do, Part INetscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long tim…
Clive Thompson@clivethompson.bsky.social

So, the DOGE kids intend to rewrite the social-security administration's COBOL code-base! and they want to do it ... ... in *a few months* I did a huge dive into COBOL a few years ago (www.wealthsimple.com/en-ca/magazi...) ... ... so let me explain why DOGE is *way* over its skis here 1/9

851 reposts2.7K likes

The most important point is that legacy code bases grow eco systems around them. And they become interdependent in often undocumented ways (e.g., the monthly abend triggering a monthly job). So rewrite this singular thing ends up growing to, rewrite the entire world. It is a fools errand.

"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work...You are wasting an outlandish amount of money writing code that already exists." 👏👏 Excellent piece of tech writing.

They don't intend to write quality software that is effective at its job. They don't know how to do that, nor do they care to learn. This couldn't be done properly in 3 months with infinite resources.

sweet cheeses on a cracker, ELON IS AN IDIOT WHY WOULD WE EXPECT ANY DIFFERENT FROM HIS IDIOT INCEL TECHWANNABE'S??? thank you for further confirmation of what is abundantly obvious, but also my intuition, and apparently that of most humans. plus, he & his li'l gang are ugly. (i feel better now.)

I was put in charge of a large healthcare 'conversion' and yes, it was successful. It was Cobol. It took 2 yrs and it was 1/10 the code SSA has. Don't believe Melon, or the felon. It is not true.

And do it using AI, no less. It just occurred to me that computer science schools could teach COBOL and other legacy languages -- maybe even assembler -- the way classics departments teach Latin and ancient Greek.

Those of us who've spent time in the Agile salt mines have been able to buck this wisdom, but it doesn't come without some serious success conditions.

While I'm here, there's always talk of rewrites around this kind of thing, and I'll throw out one law of rewrites and its corollary. The law: No rewrite of a system without comprehensive tests exercising absolutely every use case succeeds. The corollary: No use case documentation is comprehensive.

If they intended any kind of serious effort here, they’d be talking methods, requirements, etc. the cowboy method is a guaranteed fail. They aren’t trying to rewrite it, they’re trying to sabotage it.

it's also a wonderful description of why everything these idiots are doing to the government is dumb. those departments and the work they do are a product of the experience and lessons this country has learned and applied

I will wager that it'd be single digits in terms of percentages if you asked every DOGE employee, "do you know who Joel Spolsky is?" Same with the number who have read Michael Feathers' seminal "Working effectively with legacy code." Dunning-Krueger in full effect...

They know that this will break the system. Elon has to do this quickly because he only has 150 days in his position, and he needs to have his AI and his technology installed in our government agencies before his time is up. He’s running against the clock. Also, they WANT to break the system 1/

If they break the system for, let’s say, six months, no payments will be going out for six months. By the time things get fixed, and payments resume, those lapsed payments do not get sent out. They are just gone. Boom! All that money “saved”. Elizabeth Warren said something similar

Inside Bell Labs, we knew this in 1970s. Bell System had 1M+ people, already 400+ software systems written in 1950s onward. Some systems written then are still running. Redoing mission-critical S/W Is hard even for experts. Widespread UNIX adoption helped some. bsky.app/profile/john...

John Mashey@johnmashey.bsky.social

The DOGEboys’ hyper-confidence in ability to quickly reimplement huge mission-critical software is reminiscent of young Pham from Vernor Vinge’s Deepness in the Sky(1999) set 5000 years from now, which I couldn’t resist quoting: queue.acm.org/detail.cfm?i...

Ask any professor of IT Project management the success rate of large-scale system implementations, and marvel at how bad even trained, experienced companies are at this. DOGE is mostly 20 year-olds who think they’re special. They’ve no experience with this stuff. Everyone should be *horrified*.

Even among “modern” studies (mostly from consultants, not academics) the highest success estimate I’ve seen is ~30%. Most are much more pessimistic, with a mere 12–18% success rate. “Move fast and break [all the] things” indeed. The biggest failures cost *billions*.

Maybe the real lesson was the subsequent work on HTML5 that defined what exactly what browsers should do in such detail that further compatible ones could be written.

Sometimes the code is actually mess, but even then, starting from scratch is almost always the wrong answer. Even messy code can be refactored into modernity, preserving the lessons that were learned in the prior code.

You MUST ALWAYS write for the reader. No clever tricks. I know that the maintenance engineer who is going to read this in a decade or so is a psychopath and knows where I live. It's likely going to be me. If you write it as clever as you can then by definition you are too stupid to debug it.

You “might” be able to rewrite that quickly (though doubtful) but it’s the rigorous testing that MUST be performed to ensure the new code works for all cases that takes a long long time.

Generally in the software industry when we're replacing a critical service we usually run them both in parallel until the new one proves it's working properly. That DOGE isn't doing that shows that they're either clueless or they don't consider these services that millions depend on as critical.

Why are people still taking everything they say at face value? They are going to destroy it. Then they are going to loot the money. That's it. They'll lie the whole time, but at no point will they put any real work into rebuilding it.

Excellent read. If companies/governments listened to all the new software developers we'd be paying enormous amounts of money for rewrites every 5-10, years every time a new language becomes popular. Quite frankly some old code is very efficient and should not be thrown away.

Crushing pizza and Red Bulls gak'd up on yay while pulling consecutive all nighters is the consensus strategy for writing accurate, functional code that finds iterative solutions to avoid deep recursion induced stack overflow.

Here is a famous writing from someone who actually wrote hundreds of thousands lines of COBOL. These pimple faced kids would be hard pressed to UNDERSTAND let alone rewrite such a complicated system. Ask every major bank in the country who still are using COBOL and Mainframe systems.

Isn’t the big difference here that DOGE doesn’t care if they destroy the code? If social security is rendered unusable and inaccessible isn’t that still a win for them? People will be angry, but that doesn’t seem to be a consequence they care about

My son did a rewrite of a DOT system. They ran the old and new systems in parallel to compare results. He had to track down every different result, identifying errors in both systems. A long, meticulous and laborious process.

This! This!! Our first reaction is biased toward a 'rational' criticism. But this missing the point, that every incompetent decision taken is a *feature*: it leads to constant state of chaos and fear. Failures will be use to blame 'the enemies within'. This is the little fascist playbook.

Actually there is one instance I’ve encountered where this is a great idea, and that’s when it was only just written and is completely unfit for purpose!

Well, it seems logical that if they were to do it, they phase it in - set up program with a small subset and build from there. They have a grandiose idea of capabilities without knowing the system- taking lessons from EM - Mr. Don’t sink Tesla. Well, don’t sink Social Security!

One thing I've been wondering is how systems and data that DOGE has been monkeying with are backed up, and where the backups are, and who has control of them.

COBOL the computer language my engineer husband used in 1970. Same as my grandson not knowing what the pound sign # is. “Oh that’s the hashtag”. Huge generation gap.

Even Elon’s pet LLM calls bullshit: x.com/i/grok/share...

x.comPlease give me an estimate for the amount of time to correctly rewrite the social security code base. It is important that the new code be correct and that there be no errors that would affect payments to social security recipients.Estimating the time required to rewrite the Social Security codebase is a complex task, as it depends on several factors, including the size of the existing system, the programming languages involved, the number of developers assigned, their expertise, and the processes for testing and validation to ensure zero errors affecting payments. While I don’t have direct access to the Social Security Administration’s (SSA) codebase, I can provide a reasoned estimate based on publicly available information and software engineering principles. The SSA’s systems are vast, managing benefits for over 70 million Americans annually (as of recent SSA reports). The codebase likely includes millions of lines of code, much of it written in older languages like COBOL, which has been a cornerstone of SSA systems for decades. For context, large legacy systems in government—like the IRS or SSA—are often estimated to have 10-100 million lines of code. Let’s assume a conservative 20 million lines for this exercise, given the SSA’s complexity with payment calculations, eligibility rules, and integration with other federal systems. ### Key Steps and Time Estimates 1. **Requirements Analysis and Documentation (6-12 months)** - Before rewriting, the team must fully understand the current system’s logic, rules, and edge cases. Poor documentation of legacy systems often extends this phase. For a system critical to payments, this could take 6 months with a dedicated team of 20-50 analysts, or up to a year if documentation is sparse. 2. **Design and Architecture (6-12 months)** - Designing a modern, modular system (e.g., using microservices, modern databases, and languages like Java or Python) requires careful planning to ensure scalability and accuracy. This might take 6 months with a team of architects and engineers, overlapping slightly with requirements analysis. 3. **Code Rewriting (2-5 years)** - Industry benchmarks for rewriting legacy code suggest a productivity rate of 500-1,000 lines of code per developer per month, assuming thorough testing. For 20 million lines, with a team of 100 developers averaging 750 lines/month: - 20,000,000 ÷ (100 × 750) = ~267 months ÷ 12 = ~22 years. - However, with parallel development, automation tools, and code generation, this could be reduced. A realistic range with a 100-200 developer team is 2-5 years, assuming aggressive optimization and reuse of logic. 4. **Testing and Validation (1-2 years)** - Ensuring no errors affect payments requires exhaustive unit, integration, and parallel testing (running the new system alongside the old one). For a system this critical, testing could take 1-2 years, including simulations of every payment scenario and edge case. 5. **Deployment and Transition (6-12 months)** - Gradual rollout, data migration, and staff training would take at least 6 months, potentially a year, to avoid disruptions. ### Total Estimate Adding these phases, with some overlap (e.g., design starting during requirements, testing during coding), the total timeline is likely **5-10 years** with a team of 100-200 skilled developers, analysts, and testers working full-time. A smaller team or insufficient funding could stretch this to 15 years or more, while a massive, well-funded effort (e.g., 500 developers) might compress it to 3-5 years, though coordination overhead would increase. ### Critical Assumptions - **Team Size**: 100-200 people is reasonable for a project of this scale, balancing cost and speed. - **Zero Errors**: Achieving this requires extensive parallel testing, doubling validation time compared to typical software projects. - **Funding and Priority**: Government projects often face delays due to budget constraints or shifting priorities. - **Legacy Complexity**: If the codebase is poorly documented or has significant technical debt, timelines could extend. ### Real-World Precedent The SSA has modernized parts of its systems before—e.g., the Disability Determination Services transition in the 2010s took several years for a smaller scope. A full rewrite would dwarf such efforts. For comparison, the U.S. Department of Veterans Affairs’ electronic health record overhaul, a smaller but still complex system, has taken over a decade and remains incomplete as of 2025. ### Final Answer A conservative, realistic estimate to rewrite the Social Security codebase with no payment errors is **5-10 years**, assuming a well-resourced team and rigorous testing. This could vary significantly based on the actual codebase size, team efficiency, and political will.

In order to rewrite a system that uses COBOL into something that they can work with (Scratch or Blockly?) they still have to acquire a decent understanding of what each part of the current code does.

But I *guess* if your objective wasn't to produce a working system, but to just break the existing one and sell everyone's data on the Darknet, then this might be a viable strategy Pretty fucking evil one though ...

I once worked for an agency that hired some folks who didn't have a clue what we did to build a system for us. It was worthless. I was charged with inventorying the equipment they used. I reported $500,000 dollars for a computer, monitor, and keyboard. These boys also dont have a clue.