We tried guys, really we did. The vibe coding was working but it was sabotaged by liberals and Canadians. The only option is to end social security and put the poor and elderly into workhouses or send them to the shower blocks.
It would be funny except for all the old people who are going to stop getting checks and find out Musk closed their local SS office.
I thought they were working on establishing ss offices
kek
Agreed. But my first thought was
Boomers gonna love how this turns out.
Someone please make a backup
If there’s one thing you want in a website used by almost 75 million beneficiaries it’s a platform hastily put together by a crack team of geniuses–that don’t password protect databases–“in months.”
This is gonna go very very very poorly.
Well maybe the beneficiaries can edit their benefits themselves?
Calling it now - it will be written in such a way that Musk’s motley crew will be required to maintain it or update proprietary closed source components at extreme cost forever - practically guaranteeing he will always have full access to the data and be able to charge what he likes for any changes whoever takes power after Trump is gone.
It’s going to be written using vibe programming
This is going to be such a ridiculous disaster that it’d be entertaining to watch it go to shit — if it weren’t such a critical system they’re fucking with.
I’ve been party to dumping legacy systems and lift & shifts a few times.
Good fucking luck.
Knowing nothign about this, a project like this would take at least 2 years even if you are dropping a ton of use cases and dependencies.
Agreed (context: same legacy system work, 20 years), although given the size and scale of the tech debt involved, I’d peg it at 5 years if you had a team of 100+ COBOL developers.
10 to do it right.
Once you start dealing with databases older than SQL and languages older than C, things get funky real fast.
I wonder if it will be web scale
That takes me back
How does that have less than a million views? My team and I quote/use/reference it so often.
Yes. Because they’ll store everything in MongoDB.
Every time I watch it, I giggle 🤭
Years are made of months … Good read https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month
Years are made of months … Good read https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month
More than just a good read, that’s one of the project/programming Ten Commandments.
Can’t tell you how many times over the decades I’ve had to argue with project managers about that.
The best way I’ve heard it said was “if a woman can make a baby in nine months, then nine women should be able to make a baby in one month, right?”
That’s in the book :)
Also a good pen is the report, we need three months for this, only to be told each week something else is more important. After the three month the question came is it finished now.
And so 2 Years turned to 6.
Can’t wait to hear how the blockchain will factor into this redesign.
I mean, technically SSA data might be a legitimate use of the blockchain. I am one of the biggest opponents of the whole mess, but there are use cases for a persistent immutable data record, and social security numbers would be one of them.
Distributed blockchains are useful when all of the below are fulfilled:
- Need for distributed ledger
- Peers are adversarial w.r.t. contents of transactions in the ledger
- Enough peers exist so that no group can become a majority and thus assume control
- No trusted central authority exists
Here, we have a single peer creating entries in a ledger. We can get away with a copy of the ledger and one or more trusted timestamping authorities.
I didn’t say distributed. You are absolutely correct though. I was more observing that of all the BS tech bro babble that our Oligarch in Chief could spew into the universe, blockchain would be one that could be implemented reasonably.
If your blockchain isn’t distributed, it doesn’t need to be a blockchain, because then you already have trust established.
There are actually other comments on this thread that provide other benefits besides trust, like modification tracing. There is more to it than just trust.
You mean a transparency log? Just sign and publish. Or if it’s confidential, have a timestamp authority sign it, but what’s the point of a confidential blockchain? Sure, we han have a string of hashes chained together á la git, but that’s just an implementation detail. Where does the trust come from, who does the audit? That’s the interesting part.
The not-bullshit version of this already exists.
Many know it as MySQL, Postgres, etc.
Databases don’t need Blockchains.
Damn why doesn’t git just use sql instead of Merkle trees I guess that’s just stupid tell Linus to get to using SQLite asap!!!
But no, you’re wrong. Cryptographically verifiable merkle trees are a valuable way to store changing data. Unlike your recommendations, they don’t satisfy the needs of verification, which is literally a great use-case for ssns. Now I’ll admit that the SSN db doesn’t need to be distributed, which is the only thing a blockchain adds to that equation. But you are just flat out wrong for suggesting a sql db 😂
Blockchain is three things, not just a merkle tree.
- Distributed
- Cryptographically signed
- Distrust of all others on the chain.
Git isn’t a blockchain. Blockchain requires mistrust, else it’s just previous technology that existed decades before.
You can store the Merkle trees inside of a SQLite database as extra columns attached to the data.
That way you get the benefits of a high-level query language and a robust storage layer as well as the cryptographic verification.
In fact, there is a version control system called Fossil which does exactly that:
https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage adirected acyclic graph (DAG) of Merkle tree structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via the parent’s hash.
The difference is that Git stores its objects as individual files in the
.gitfolder or compressed into bespoke key/value pack-files, whereas Fossil stores its objects in a SQLite database file which provides ACID transactions and a high-level query language. This difference is more than an implementation detail. It has important practical consequences.[…]
The SQL query capabilities of Fossil make it easier to track the changes for one particular file within a project. For example, you can easily find the complete edit history of this one document, or even the same history color-coded by committer, Both questions are simple SQL query in Fossil, with procedural code only being used to format the result for display. The same result could be obtained from Git, but because the data is in a key/value store, much more procedural code has to be written to walk the data and compute the result. And since that is a lot more work, the question is seldom asked.
Or you know, trusted timestamps and cryptographic signatures via normal PKI. A Merkle tree isn’t worth shit legally if you can’t verify it against a trust outside of the tree.
All of the blockchain bullshit miss that part - you can create a cryptographic representation of money or contracts, but you can’t actually enforce, verify or trust anything in the real world without intermediaries. On the other hand, I can trust a certificate from a CA because there are verifiable actual real-world consequences for someone if that CA breaks legal agreements.
I’ll use a folder of actual papers, signed using a pen. Have some witnesses, make sure they have a legal stake and consequences, and you are golden.
My heart breaks for cool ideas that got taken by scammers and are now forever associated with financial predators and will probably never see legitimate use.
Except that the numbers are also prone to change, like if it’s been stolen. They’re technically not supposed to be an identification code anyhow.
Right, but you can have entries in a block chain that indicate previous entries are no longer valid, or have modifications. Calculating a final state by walking through all the blocks in the chain. ( A bit like a CQRS based system can have a particular state at a point in time by replaying all events up to that point)
Doing it in such a way also makes auditing what’s happened much easier since changes are inherently reflected in the chain. You want to know when (or by who if you keep that information) a record changes, it’s right their in the chain.
Remember when people thought Elmo knew anything?
Pepperidge Farm remembers.
I 'member.
This is going to really help government efficiency!
We also got fully self driving cars in 2 years though, in 2016…
I’m posting this from Mars colony. Amazing isn’t it.
COBOL systems, when properly maintained, are highly reliable, with built-in redundancy and fault tolerance.
They can’t have that because they want excuses when it goes down and leaves old people to starve and ruin their credit.
Basically, a VBA Excel file.
