I dont even program and i could've told them it was probably a placeholder or default value lol "durrrrrr lot of people in this database were born at the exact same time on the same day in the same year that predates electronic databases, gotta be fraud!!1!1!11"
2016-2020 was the age of too stupid to break everything. Now we're staring down the barrel of "The files are in the computer?" But the entire US government is the computer.
I don't know how many teenage programmers you have interacted with recently, but they are generally just learning the basics, learning core concepts, experimenting, etc...
There is a huge gap between making small, sometimes very cool and creative even, projects and understanding a giant legacy codebase in a language that is not taught anymore. I mean, even university grads often have trouble learning legacy code, much less in COBOL.
You wouldn't say your average teenage cook could make a gourmet meal for a house of 50 people 😅 not a dis, just they haven't had the time to get to greybeard level yet
How many teens you think can actually read and understand legacy languages like FORTRAN and COBOL? Let alone a complex codebase written in them?
I studied COBOL a bit in college and it's not exactly hard to read short snippets if you understand other languages, but good luck wrapping your head around anything remotely complex and actually understand what it is doing without having someone who understands the language. Hell, 15-20 years on and multiple languages later, my eyes still cross trying to read and grok COBOL. The people supporting those old code bases get paid well for a reason ...
Heh, you are correct, it's always the why, even in a language you work with every day. It's hard even if it is you who wrote it if you don't remember the why, and then add an unknown code style and an unfamiliar domain. And on top of that maybe multiple projects interacting and I feel the burnout threaten I have to think of something else for a while 🫨
I'm familiar with a dozen or so teenage romhackers. Assembly is surely harder to get the big picture of than cobol, but they're making incredible changes to 30-yo video games.
The issue isn't inherently age it's just time and experience, understanding different coding patterns and paradigms that have changed over the years etc. Even someone who's been coding every day from ages 14-20 can't have the same knowledge and experience as someone who's been working with software since the 90s or earlier. Granted, there will always be brilliant people who even when lacking experience are more talented and skillful than maybe the majority, but that is uncommon. I'm only in my late 20s. And I remember in college there was a huge diversity of skills, from "are you sure this career path is really a good idea for you?" To "holy hell how did you do all of that in one hackathon?" But even for those really smart folks, they aren't just going to inherently understand all the different ways to organize and structure code, all the conventions that exist, and more importantly why those methods and structures exist and the history that informed them. I'm not saying you need on the ground experience (although, I'd say many people do, as many people can't really internalize things without direct exposure), but there's just not enough time, literally, in the handful of years that is childhood and teenage years to absorb all that history.
Anyway, what I'm getting at is that, yes, I agree that the problem isn't inherently about being teenagers but I do think it's a valid criticism that it's kind of ridiculous to have such young folks leading this kind of project given it's literally impossible for them to have the same amount of experience as software vets. It's also valid that young people are capable of seeing things in very new ways, since they aren't weighed down by al that history. But that's why diversity is useful especially for such a monumental project as this.
I think it makes sense that people who don't have actual experience in making projects in a specific language won't be aware of details such as the value 0 being the default in a certain kind of field in a certain language which makes it a good flag for "data unknown".
This is not a problem specific of teenage programmers - it is natural for just about everybody to not really know the ins and outs of a language and best practices when programming with it, when they just learned it and haven't actually been using it in projects for a year or two at least.
What's specific to teenagers (and young coders in general) is that:
They're very unlikely to have programmed with COBOL for a year or two, mainly because people when they start tend to gravitate towards "cool" stuff, which COBOL hasn't been for 4 decades.
They haven't been doing software engineering for long enough to have realized the stuff I just explained above - in their near-peak Dunning-Krugger expertise in the software engineering field, they really do think that learning to program in a given language is the same as having figured out how to properly use it.
my brother taught me to code when i was 6, so at 19 i had 13 years of experience already. At 6 i was mostly doing simple stuff like qbasic, vb6, but still it adds up. I'm not saying I'm a great coder, not by a long shot, just that I was experienced as a teenager. I assume a lot of these teenagers are much better than i was.
I taught myself coding at 14 on a ZX Spectrum 128 and was doing Assembly within 2 years.
By now I have over 3 decades professional software engineering experience, almost 4 decades in total if including the stuff I did non-professionally.
Looking back, I knew how to make programs (even made a Minesweeper for the Spectrum in Assembly) but that's not at all the same as knowing the good or industry standard practices in the languages I used.
Whilst it should be way easier now to find those things out (there was no Internet back when I started), in my experience one needs to actually have been coding in a spaghetti way long enough and in enough projects you can't just ditch if they get too messy to actually feel the need to learn those better ways and hence go search for it.
Also I bet that it's a lot harder to find advanced tutorials on COBOL on the net from people with actual experience doing it professionally for a couple of years than it is for, say, Python.
I've been surprised multiple times by coworkers who don't know the significance of midnight January 1st 1970... We support an embedded Linux device, among other things...
I think it makes sense that people who don’t have actual experience in making projects in a specific language won’t be aware of details such as the value 0 being the default in a certain kind of field in a certain language which makes it a good flag for “data unknown”.
The whole "COBOL's default date is 1875" thing is just a lie. COBOL doesn't even have a date type.
So the problem doesn't have anything to do with COBOL, someone just made it up
The way I'm reading is that they were holding a date related value in an unsigned integer field, so the start date (corresponding to 0) was a convention (whether internal or broader than that, I don't know) and they chose 0, the default initialization value for such fields as a flag for "no information". Back in the day there wasn't all that memory and storage to go around so I bet this was a 1 byte field holding a year value.
Those choices in a system to be used for Social Security for a whole nation make sense in software design terms if you're having to come up with your own solution for storing dates in as fewer bytes as possible in a language with no built-in date type, but present day teenagers would have never have been in such a situation because there are no currently fashionable programming languages without date types, space isn't as constrained anymore and they don't have experience in the kind of projects were one has to store records for hundreds of millions of people.
Not only do many important government systems ultimately rely on or make heavy use of COBOL...
So do many older private companies.
Like banks. Account balances, transactions.
Its actually quite a serious problem that basically nobody who needs to take seriously actually does.
Basically no one is taught COBOL anymore, but a huge amount of code that undergirds much of what we consider 'modernity' is written in COBOL, and all the older folks that actually know COBOL are retiring.
We're gonna hit a point where the COBOL parts of a system to be altered or maintained, and ... there just isn't anyone who actually knows how to do it.
That is absolutely true as well... though this may be just a personal anecdote, it seems to me that the few COBOL coders I once knew would be amongst the most likely to keep a solid documentation of their own systems.
The problem with that though, is that their bosses are almost always too stupid to ask them for such documentation before they leave/retire, or to bother to preserve it when the exiting COBOL programmer gives it to them, because coding is magic to them, and you're either a good magician that can do the thing, or you're not.
Upper management / C Suite seems to never understand why the term software engineer was/is used.
Yeah, I’ve been tempted to try this route, but you’re really pigeonholing yourself. Even if there’s always wrk, I can’t imagine only working with cobol the rest of my career.
Even worse, the places still using this are very heavy in process, with many undocumented dependencies among many undocumented workflows and business processes. Modernizing COBOL is not a coding problem: it’s a mammoth project management, coordination, and paperwork project that also has a little bit of coding. And its not like you can write clean code, you need to write essentially the same tangled mess of accumulated changes over decades because there’s no way of knowing everything that might break
I hereby nominate you to be the new head of the SSA.
You get it, exactly.
COBOL itself is a fairly minor part of the problem, the real problem is the retiring COBOL coders are the only ones with enough institutional knowledge, broad and specific, to keep the engine from grenading and fucking wheels from coming off the car when it hits a bad enough pothole.
But management and C Suite are apparently homo superior, fully confident that none of that really matters, they'll just keep throwing money at it until its fixed, and failing that, laying off everyone, who care in the end, they get a golden parachute when it all burns, everyone else can FOAD.
The actual payment system stops payments automatically at age 115 and requires manual verification to restart. The database that is being reported is not even a report of who is getting paid.
This is just dramatic, public evidence of the arrogance and incompetence of DOGE from down to his racist younglings.
For a while, I thought they would at least be good at technology. This episode shows that even that is not true.
How he chose this elite group of chuckleheads is an eyebrow raiser. Other than racism, they seem to have no credentials at all. I mean, on brand for this administration I guess.
In my experience in the legacy world we have the isHighDate function which not only checks the constant, but also 5 other edge cases where the value isn't HIGH_DATE but should be treated as if it is.
Jesus fucking christ the interns who have neither seen nor heard of COBOL have also not encountered the concept of a sentinel value used as a fallback/default.
What do you expect? most of the guys in "DOGE" weren't even alive on 9/11
I'm a bit surprised that they still have something in COBOL, maintenance probably costs o fortune, good luck finding young COBOL devs
I'm ready to learn COBOL. I will take up the torch. If you know good places to start, let me know. Last time I looked into it it seems way more involved than running stuff like Python, Java, and C.
I see, you want that that Lamorghini, well if you really want udemy is always a good start. Personally the difficult part for me when learning a new programing language is not resources, it's the motivation to keep do it and I usually need a real project to work on. (10 years + dev)
Usually you find on github "awesome-XYZ" repos (ex: awesome python, awesome c, awesome go), but for cobol, most of the projects are dead
It's a niche, most of the companies use something more modern, easier to find devs, but there are still some that have to mentain that old code while they probably at the same time try to replace it with some other more common language (Java, C++, Rust, Go), I think it's still used by some legacy systems in governments and financial institutions
It's like knowing an extinct language, most of the time is useless, but if someone needs your skills they better pay good for it.
Date time types have long since been based on a 64 bit number , at least in Linux. However the old 32 bit date time types are still there so older programs won’t break, and probably on emdpbedded systems.p. So it comes down to the apps: how many old apps or old embedded systems will still be around?
It will be interesting to see that play out. The thing is the 238 prboem spas long been solved just like the y2k problem was.
The Linux datetime types were moved to 64 bit values long ago, so this problem is thousands of years out. The old 32 bit values was a limitation of older systems not handling larger values, but almost all hardware today is either 64 bit or has hardware support for 64 bit data. You mainly have some older embedded systems
But the legacy 32 bit APIs are still there so it doesn’t break backward compatibility. You have huge ecosystems of software that still use these APIs and may still handle datelines as 32bit. There’s no way to find them all, much less make sure they’ve been updated.
Just like y2k, 2038 will have been a long solved issue, that may still exist due to ancient or poorly written applications. All you can do is a huge effort of trying everything to find any remaining issues before they cause problems. I’m optimistic because y2k was a problem cased by every application handling their own dates, whereas for 2038 its cause was in an underlying data type that has long since been fixed. Surely all applications will have been rebuilt to the new API in that 20 year or so period, right? Right?
More specifically, they didn't find anyone receiving social security who were 150 years old because they didn't prove that they were receiving anything as that's not the purpose of that database.
Less of a generational problem, more of an educational one.
Selfish, badly educated grifters that got pushed into high offices can be of any age. Musk also didn't recognize SQL when he looked at it, which is arguably even more funny.
I get this feeling too, but then again can we blame them? With all the locked down tech these days you really have to get out of your way to learn. And in most cases it works well enough. Whereas people growing up between lets say the 1970-2000s had to muck around with their tech to get it to work. Thus learning the intricacies while using it.
There is no "date" data type in COBOL. Dates are stored however the programmer wants, but usually numeric character strings
There's no "default" date, even if there were such a data type
Even if there were a default, 1875 would be a bizarre choice
That (obviously) doesn't mean Elon Musk is right. It just means that this explanation of it being some magical COBOL epoch value is wrong. What's more likely is that the Social Security database is very old and has a lot of iffy data in it.
My guess is that it contains everybody who has ever had a social security record, including all the duplicates, all the typos, and everything else. At some point there were probably hundreds of thousands of records that were transcribed from paper into a computer, and it was considered safer to keep the iffy data and make a plan to deal with it later, vs. remove someone from the database who should legitimately be there.
I would also imagine that the systems that take the records out of the DB probably have filters in place that remove the (known) bad records before they're used.
There is no "date" data type in COBOL, but there is in DB2, where the data would be saved, unless they are on an older VSE OS and data is still saved in VSAM files. Many still use 12/31/39 as a default max date even though OS/400 systems can handle up to year 9999 now (we still use 12/31/39 in testing where I work). It could be someone arbitrarily started using 1875, and others copied that.
As someone who is working on a project of recreating an enterprise application in a modern tech stack, the legacy code is hard to understand too.
We have something similar in that a ClaimClosedDate is defaulted to 01/01/1900 and if it has that date it means it’s not closed whereas now that would be a nullable field.
There are many people who were born in developing nations during times of war who do not know their exact age. They usually do have an idea of a range though.
Jay Kuo is wirth worth following. I know people dislike substack, but a lot decent people publish there. Jay Kuo is good at breaking down the legal aspects of the mess we are seeing now
I share this sentiment, and I admit I am not entirly aware of the Substack situation tbh. The issue is that these people, often very good journalists need a platform that generates revenue for them. I am not American, but find that people like Kuo, Jennifer Rubin, Robert Reich and Joyce Vance give valuable insights on American politics, and "sound bites" that can be share. But they need lir financial support to do this.
It's because that explanation isn't correct. The real deal is you just have entries without a death date, so if you ran a query this get super old ages as a result.
Note that isn't a database of payments or even people eligible for them, just a listing of 'everyone' with a SSN. There is a separate master death index. In the old days, wild west kind of stuff people would disappear so the death date would never get entered. Modern days every morgue and funeral home has to legally notify SS when someone dies, there is a specific form and major hell to pay if you don't do it.
Social Security numbers were first issued in 1937. You would have need someone to be over 110 in 1937 to have an age over 200. I think that it's a combination of birthdays entered wrong plus no official death date.
I think those are related to survivor benefits. Like an old man marrying a young woman in the 40's. Like the civil war vets marrying woman in the 20th century. The last civil war widow was getting benefits until she died in 2020. But still the same basic issue.
But in that case the old man isn't getting benefits but just is needed as a reference for the person actually getting them.
Also a lot of people between 110 and 150, so I'm sure there is a larger answer.
However, Social Security cuts off at 115, and they supposedly found like 10 million people older than that. Considering there are only ~50m people on Social Security, and the database they were searching wasn't even about current recipients, most people would conclude that there is likely an error in data, rather than immediately jump to fraud. Of course, ketamine is a hell of a drug and Elon is not most people.
the database doesn't have to necessarily be accurate if there's other checks - a flag for test data, a system that checks the person is real against another database before dispersing funds etc
A minor grammar point: in this context, the word is actually "disbursing," from the same root as "bursar," a job title you may have encountered in school administrations. "Disbursing" means "paying out from a fund." "Dispersing" means "scattering" or "causing to dissipate." So the old system was disbursing funds. The new system will be dispersing funds.
Someone with the skills and knowledge to clean up 150-year old typographical errors in one particular table in the Social Security database system would probably provide more benefit to the taxpayers covering their salary by doing some other task.
How would you clean up that data? If they didn’t have the correct data in the first place, where do you expect to find it decades later?
Sometime real life is just bad data and that’s not necessarily a problem. All of the business logic and agency process around not spending money for those situations is probably one of the difficult areas blocking modernization or shrinkage. Bad data is reality. How you handle it shows how experienced you are
It might be better to move to a new database at this point rather than trying to fix the existing one. It won't give immediate benefits but could be helpful down the line.
I am hoping California ditches SSN and other identifiers from the US Treasury. That information is no longer safe, so we need a fresh database that is secure from DOGE fuckery, among many other hostile actors.
Fixing an archival dataset that doesn't even pertain to people actively receiving benefits is so far down the list of priorities as to be a criminal misuse if resources.
Maybe, but you don’t know that. You only know the data you have doesn’t make sense. You can’t just make something up and claim it’s correct: you have no way of knowing what the real data is , nor are you an authority
It’s probably logical to not pay out social security for 900 years, but that’s just an additional business process for handling bad data
I also have doubts about the correctness of the specific claim, but of course there’s bad data. How could there not be? That doesn’t mean you can claim fraud, it means you can check with the processes that keep money from being sent out where there is bad data.
I especially had a chuckle from the article where they said 90,000 claims are being sent out for people 100 yr old or more ….. yet the claim is that 10 million of those are fraud?
Conspiracy theory: They know this, but being able to claim to their followers, with official records to show for it, who know NOTHING about programming, is an easy, effective win for them. They can claim fraud to their gullible audience and now have records they can point to and say "LOOK! THEY'RE GIVING DEAD PEOPLE SOCIAL SECURITY MONEY!"
COBOL doesn't have a date type. And there were "people" in that "list" that weren't just 150 years old, and they varied in ages.
The real answer is that the list that they're saying is people getting social security, isn't the list of people getting paid, just lists of random ages in the database, which ultimately means nothing.
You do realize that what you are suggesting (Musk trying to destroy social security) just isn't what is happening in reality. Anyone that has been receiving SS still is, still receiving the same amount they historically have, and it has all been verified.
1875 has never been an epoch anywhere, on any system. 1970 has. 1900 has. 0000 has. But 1875? No, it hasn't. And no where in the cobol spec does 1875 appear.
This is just propaganda. He already does enough wrong, you guys lying about it just makes everything else you say suspect.
Not true, I picked a random revision of the Wikipedia article from October 2022, and it already had the part about 1875:
ISO 8601:2004 fixes a reference calendar date to the Gregorian calendar of 20 May 1875 as the date the Convention du Mètre (Metre Convention) was signed in Paris (the explicit reference date was removed in ISO 8601-1:2019).
I'm pretty sure this has been in the Wikipedia article for even longer, considering that it dates back to 2001. I'm just too lazy to go through the entire history and check when it was added. But definitely not 2 days ago.
I was intrigued by this article as 1865 isn't any epoch I've heard about and I didn't think COBOL really had a concept of an epoch (an epoch matters when you're counting milliseconds from zero, COBOL stores date/time info differently). I've been searching this morning and can only find the Wikipedia page mentioning that date - which is weird for an ISO standard that is 99% about date formatting.
Yeah I've only heard of the 1970 epoch too, I didn't realise different languages had different epochs honestly! Interesting stuff. I've never worked with COBOL but my old boss was learning it a few years ago, it's used a lot in banking right?
It's used in mainframes mostly. I don't know COBOL well but I've worked with COBOL systems in the past. I didn't think it even has a "date type" (at least in older systems? maybe it was added at some point?). They just store dates as 8 digits (6 back in the day which led to infamous "y2k" problems). That's why I didn't think they had an epoch. In more modern systems a date is typically "the number of milliseconds since the epoch". For Linux that's 01/01/1970. Either way this explanation for Musk's error is pretty sus. I'm sure he's misunderstanding something (he didn't think the US government used SQL ffs) though.
Edit: It's possible this particular team used that date as some sort of special value. That would be pretty common in older programming styles. But it doesn't seem like it's any sort of "standard."
A lot of people online are calling it a reference date, whatever that means. An epoch data doesn’t even make sense since there isn’t really a date time type. I can see reason to doubt, but that’s not relevant.
However it could be important to the app. Perhaps at some point they decided there needed to be a cutoff because anything older was bad data. OR perhaps back in the days where storage was extremely expensive it was important to save a byte for every row.
Even if the specific claim about 1875 is wrong, that doesn’t change anything. The reality is bad data exists, there doesn’t seem to be any indication of it being paid out, and the claim of fraud is assinine
Just in case you didn't know, the code is old, but the hardware still gets updates. And when it comes to batch transactions and network speed, mainframes still do the job reliably well. Plus, they are not easy to hack, because few understand them, not to mention the decades of security updates.
It hasn’t been done because that’s a great works project that’s on a scale you’re woefully ignorant to (this is an assumption on my part based on what I can grok of you based on your comments here).
I assure you there is a bevy of skilled developers who would love to modernize the systems they work on but the cost and level of effort is beyond what is politically viable.
If you changed your perspective from “it’s awful and bad and always will be” to “it’s awful and bad and we can make it better, how can I help” things will improve for everyone.
Mate, from reading the comments of this no-brains, he or she doesn't even know how to program in a professional capacity, much less have even the slightest clue of the scope of such a project.
That one is literally a mindless Trump/Elon fan wading into waters way, WAY, WAY beyond his depth.
I guarantee you that there are no governments, banks, or businesses older than 15 years that aren't running some old ass code that's not getting replaced any time soon.
This is the part everyone is missing. Real life is messy and sloppy and incomplete. Real life has bad data. All the time, especially when you’re trying to match 100 year old records. Not handling bad data s a problem of inexperience, regardless what technology you use. Announcing it as fraud, is just being an ignorant asshole.
That being said, if Musk is willing to put out the billions of dollars it would cost to modernize, that would be great! But it still has to handle bad data. Maybe musk could add hundreds of millions to the budget to hire enough people to manually confirm all the data from before the records were digitized. Good luck with that
If you want actual proof of this, look at your medical records. And I say this as a healthcare worker. All kinds of nonsense ends up in the chart for a myriad of reasons.
And that’s with modern record keeping where there are all safeguards and things are eventually digitized. Imagine the days when it was only on paper at some hospital where the records room was damaged in a flood or it wasn’t digitized for half a century so no way to check the handwriting, or the person had a strong accent or some dirt or mold fuzzed the paper, etc …..
I am one of the millions of people in the US whose name was fudged by immigration officials at Ellis Island. We know the name they wrote down and we have the family claim of what it used to be, by Mon objective way to prove it or to know why. To make this anecdote crazier, my parents went back to the old country to find records. However this was the height of the Cold War and it was behind “the iron curtain” so they were prevented from leaving their hotel under threat f arrest as spies
Well don't worry. You're allowed to change your mind at any point in time once you realize the mistakes you've made regarding the trust and belief you've put in these people.
So spend a chunk of money to hire a team to upgrade the database that's working to one that's programmed in a new language, might will have errors, then have to fix those errors, and you'd also have to train the existing team or replace them with someone who knows how to use and maintain the new database. You'd potentially want to upgrade or change the hardware too from an old mainframe computer unless you want to only sidegrade to like C-90 since your old IBM computer won't support newer compilers. In the meanwhile there's a HUGE risk of breaking something or even just not getting anything accomplished
It's definitely an objective that's good but if you're chasing efficiency and cutbacks, it's the opposite of what you'd want to do.
LMAO watch the US be saved by an inability of Muskys frat bois to understand COBOL
I dont even program and i could've told them it was probably a placeholder or default value lol "durrrrrr lot of people in this database were born at the exact same time on the same day in the same year that predates electronic databases, gotta be fraud!!1!1!11"
Also predates social security. It's the long con for sure.
John Gomez, John Smallberries, John Bigboote, John Yaya... November 1st 1939.
More likely they nuke it due to that lack of understanding.
2016-2020 was the age of too stupid to break everything. Now we're staring down the barrel of "The files are in the computer?" But the entire US government is the computer.
They'd probably just delete the Cobol code since "nobody would use that old stuff anyway".
Teenage programmers can understand legacy code. These ones didn't. Don't dis teen coders.
I don't know how many teenage programmers you have interacted with recently, but they are generally just learning the basics, learning core concepts, experimenting, etc...
There is a huge gap between making small, sometimes very cool and creative even, projects and understanding a giant legacy codebase in a language that is not taught anymore. I mean, even university grads often have trouble learning legacy code, much less in COBOL.
You wouldn't say your average teenage cook could make a gourmet meal for a house of 50 people 😅 not a dis, just they haven't had the time to get to greybeard level yet
That makes way too much sense.
I would imagine these teens didn't learn through the conventional educational channels.
How many teens you think can actually read and understand legacy languages like FORTRAN and COBOL? Let alone a complex codebase written in them?
I studied COBOL a bit in college and it's not exactly hard to read short snippets if you understand other languages, but good luck wrapping your head around anything remotely complex and actually understand what it is doing without having someone who understands the language. Hell, 15-20 years on and multiple languages later, my eyes still cross trying to read and grok COBOL. The people supporting those old code bases get paid well for a reason ...
Learning to COBOL is not itself that hard.
Understanding decades of "business" logic is.
It isn't WHAT it is doing, it's WHY it is doing it that makes these systems labyrinthian.
Also afaik they don't get paid that well which is part of the problem.
Heh, you are correct, it's always the why, even in a language you work with every day. It's hard even if it is you who wrote it if you don't remember the why, and then add an unknown code style and an unfamiliar domain. And on top of that maybe multiple projects interacting and I feel the burnout threaten I have to think of something else for a while 🫨
I'm familiar with a dozen or so teenage romhackers. Assembly is surely harder to get the big picture of than cobol, but they're making incredible changes to 30-yo video games.
The issue isn't inherently age it's just time and experience, understanding different coding patterns and paradigms that have changed over the years etc. Even someone who's been coding every day from ages 14-20 can't have the same knowledge and experience as someone who's been working with software since the 90s or earlier. Granted, there will always be brilliant people who even when lacking experience are more talented and skillful than maybe the majority, but that is uncommon. I'm only in my late 20s. And I remember in college there was a huge diversity of skills, from "are you sure this career path is really a good idea for you?" To "holy hell how did you do all of that in one hackathon?" But even for those really smart folks, they aren't just going to inherently understand all the different ways to organize and structure code, all the conventions that exist, and more importantly why those methods and structures exist and the history that informed them. I'm not saying you need on the ground experience (although, I'd say many people do, as many people can't really internalize things without direct exposure), but there's just not enough time, literally, in the handful of years that is childhood and teenage years to absorb all that history.
Anyway, what I'm getting at is that, yes, I agree that the problem isn't inherently about being teenagers but I do think it's a valid criticism that it's kind of ridiculous to have such young folks leading this kind of project given it's literally impossible for them to have the same amount of experience as software vets. It's also valid that young people are capable of seeing things in very new ways, since they aren't weighed down by al that history. But that's why diversity is useful especially for such a monumental project as this.
I think it makes sense that people who don't have actual experience in making projects in a specific language won't be aware of details such as the value 0 being the default in a certain kind of field in a certain language which makes it a good flag for "data unknown".
This is not a problem specific of teenage programmers - it is natural for just about everybody to not really know the ins and outs of a language and best practices when programming with it, when they just learned it and haven't actually been using it in projects for a year or two at least.
What's specific to teenagers (and young coders in general) is that:
my brother taught me to code when i was 6, so at 19 i had 13 years of experience already. At 6 i was mostly doing simple stuff like qbasic, vb6, but still it adds up. I'm not saying I'm a great coder, not by a long shot, just that I was experienced as a teenager. I assume a lot of these teenagers are much better than i was.
I taught myself coding at 14 on a ZX Spectrum 128 and was doing Assembly within 2 years.
By now I have over 3 decades professional software engineering experience, almost 4 decades in total if including the stuff I did non-professionally.
Looking back, I knew how to make programs (even made a Minesweeper for the Spectrum in Assembly) but that's not at all the same as knowing the good or industry standard practices in the languages I used.
Whilst it should be way easier now to find those things out (there was no Internet back when I started), in my experience one needs to actually have been coding in a spaghetti way long enough and in enough projects you can't just ditch if they get too messy to actually feel the need to learn those better ways and hence go search for it.
Also I bet that it's a lot harder to find advanced tutorials on COBOL on the net from people with actual experience doing it professionally for a couple of years than it is for, say, Python.
I've been surprised multiple times by coworkers who don't know the significance of midnight January 1st 1970... We support an embedded Linux device, among other things...
The whole "COBOL's default date is 1875" thing is just a lie. COBOL doesn't even have a date type.
So the problem doesn't have anything to do with COBOL, someone just made it up
The way I'm reading is that they were holding a date related value in an unsigned integer field, so the start date (corresponding to 0) was a convention (whether internal or broader than that, I don't know) and they chose 0, the default initialization value for such fields as a flag for "no information". Back in the day there wasn't all that memory and storage to go around so I bet this was a 1 byte field holding a year value.
Those choices in a system to be used for Social Security for a whole nation make sense in software design terms if you're having to come up with your own solution for storing dates in as fewer bytes as possible in a language with no built-in date type, but present day teenagers would have never have been in such a situation because there are no currently fashionable programming languages without date types, space isn't as constrained anymore and they don't have experience in the kind of projects were one has to store records for hundreds of millions of people.
In before Musk says "You think the government uses COBOL?!"
I don't think the government uses COBOL. I know the government uses COBOL.
It doesn't matter what I think or know, the government uses COBOL.
He would dismiss COBOL and try to prove that he is a super cool geek with a deep knowledge of DnD and gaming culture. So more like:
"COBOL? Such a language doesn't even exist unless you think Kobolds are real! Hahaha"
Not only do many important government systems ultimately rely on or make heavy use of COBOL...
So do many older private companies.
Like banks. Account balances, transactions.
Its actually quite a serious problem that basically nobody who needs to take seriously actually does.
Basically no one is taught COBOL anymore, but a huge amount of code that undergirds much of what we consider 'modernity' is written in COBOL, and all the older folks that actually know COBOL are retiring.
We're gonna hit a point where the COBOL parts of a system to be altered or maintained, and ... there just isn't anyone who actually knows how to do it.
My understanding is that even if you learn COBOL, you'd struggle to understand legacy systems since they have their quirks from a bygone era
That is absolutely true as well... though this may be just a personal anecdote, it seems to me that the few COBOL coders I once knew would be amongst the most likely to keep a solid documentation of their own systems.
The problem with that though, is that their bosses are almost always too stupid to ask them for such documentation before they leave/retire, or to bother to preserve it when the exiting COBOL programmer gives it to them, because coding is magic to them, and you're either a good magician that can do the thing, or you're not.
Upper management / C Suite seems to never understand why the term software engineer was/is used.
Yeah, I’ve been tempted to try this route, but you’re really pigeonholing yourself. Even if there’s always wrk, I can’t imagine only working with cobol the rest of my career.
Even worse, the places still using this are very heavy in process, with many undocumented dependencies among many undocumented workflows and business processes. Modernizing COBOL is not a coding problem: it’s a mammoth project management, coordination, and paperwork project that also has a little bit of coding. And its not like you can write clean code, you need to write essentially the same tangled mess of accumulated changes over decades because there’s no way of knowing everything that might break
I hereby nominate you to be the new head of the SSA.
You get it, exactly.
COBOL itself is a fairly minor part of the problem, the real problem is the retiring COBOL coders are the only ones with enough institutional knowledge, broad and specific, to keep the engine from grenading and fucking wheels from coming off the car when it hits a bad enough pothole.
But management and C Suite are apparently homo superior, fully confident that none of that really matters, they'll just keep throwing money at it until its fixed, and failing that, laying off everyone, who care in the end, they get a golden parachute when it all burns, everyone else can FOAD.
The actual payment system stops payments automatically at age 115 and requires manual verification to restart. The database that is being reported is not even a report of who is getting paid.
This is just dramatic, public evidence of the arrogance and incompetence of DOGE from down to his racist younglings.
For a while, I thought they would at least be good at technology. This episode shows that even that is not true.
How he chose this elite group of chuckleheads is an eyebrow raiser. Other than racism, they seem to have no credentials at all. I mean, on brand for this administration I guess.
Found the link to the SSA page describing the policy which took effect in 2015.
They dont care they want to take all the ss money its that simple
115 sounds too late imo, payments should need manual verification way earlier
If that's what you want they should be staffing up instead of firing.
Absolutely, DOGE is obviously committing crimes doing what they are doing
There are other verification procedures in place as well. This is something like a failsafe.
They’re going to need lots more people going around talking to old people because you don’t want to rely on public records
Too bad he let go of all the employees that would be responsible for that manual verification.
I can't wait for them to discover a bunch of people who are 9999 years old next.
In the legacy world we just call it the HIGH_DATE constant.
In my experience in the legacy world we have the isHighDate function which not only checks the constant, but also 5 other edge cases where the value isn't HIGH_DATE but should be treated as if it is.
Or supposedly received 9.223.372.036.854.775.807 dollars (64-bit max int).
Jesus fucking christ the interns who have neither seen nor heard of COBOL have also not encountered the concept of a sentinel value used as a fallback/default.
These are the same interns that are pushing code in production, right?
What do you expect? most of the guys in "DOGE" weren't even alive on 9/11 I'm a bit surprised that they still have something in COBOL, maintenance probably costs o fortune, good luck finding young COBOL devs
I'm ready to learn COBOL. I will take up the torch. If you know good places to start, let me know. Last time I looked into it it seems way more involved than running stuff like Python, Java, and C.
I see, you want that that Lamorghini, well if you really want udemy is always a good start. Personally the difficult part for me when learning a new programing language is not resources, it's the motivation to keep do it and I usually need a real project to work on. (10 years + dev)
Usually you find on github "awesome-XYZ" repos (ex: awesome python, awesome c, awesome go), but for cobol, most of the projects are dead
https://github.com/loveOSS/awesome-cobol?tab=readme-ov-file#email
Is being a COBOL dev something that can get you jobs?
I’m pretty good at FORTRAN and would love that kind of “you have invaluable skills so we can’t get rid of you for being queer” gig.
It's a niche, most of the companies use something more modern, easier to find devs, but there are still some that have to mentain that old code while they probably at the same time try to replace it with some other more common language (Java, C++, Rust, Go), I think it's still used by some legacy systems in governments and financial institutions
It's like knowing an extinct language, most of the time is useless, but if someone needs your skills they better pay good for it.
Cant wait till 2038!
Date time types have long since been based on a 64 bit number , at least in Linux. However the old 32 bit date time types are still there so older programs won’t break, and probably on emdpbedded systems.p. So it comes down to the apps: how many old apps or old embedded systems will still be around?
How many cobol systems are still around in 2025. If it works, don't fix it. And I have a feeling a lot of things will need fixing in 2038 lol
It will be interesting to see that play out. The thing is the 238 prboem spas long been solved just like the y2k problem was.
The Linux datetime types were moved to 64 bit values long ago, so this problem is thousands of years out. The old 32 bit values was a limitation of older systems not handling larger values, but almost all hardware today is either 64 bit or has hardware support for 64 bit data. You mainly have some older embedded systems
But the legacy 32 bit APIs are still there so it doesn’t break backward compatibility. You have huge ecosystems of software that still use these APIs and may still handle datelines as 32bit. There’s no way to find them all, much less make sure they’ve been updated.
Just like y2k, 2038 will have been a long solved issue, that may still exist due to ancient or poorly written applications. All you can do is a huge effort of trying everything to find any remaining issues before they cause problems. I’m optimistic because y2k was a problem cased by every application handling their own dates, whereas for 2038 its cause was in an underlying data type that has long since been fixed. Surely all applications will have been rebuilt to the new API in that 20 year or so period, right? Right?
I expect governments to set up own time servers and reset it to 1970 before upgrading their old Win XP machines.
More specifically, they didn't find anyone receiving social security who were 150 years old because they didn't prove that they were receiving anything as that's not the purpose of that database.
Honestly, if you make it to 150 you deserve the money
I keep hearing that gen Z is actually pretty shit with understanding things outside GUIs.
And now I’m watching it actively destroy my country.
Less of a generational problem, more of an educational one. Selfish, badly educated grifters that got pushed into high offices can be of any age. Musk also didn't recognize SQL when he looked at it, which is arguably even more funny.
How dare you question the wisdom of Big Balls and his peers
Dangerous like an epileptic deer with 15 pairs of scissors taped to its head and body
I get this feeling too, but then again can we blame them? With all the locked down tech these days you really have to get out of your way to learn. And in most cases it works well enough. Whereas people growing up between lets say the 1970-2000s had to muck around with their tech to get it to work. Thus learning the intricacies while using it.
More of a late gen z, gen alpha thing.
I’m gen z, I use Vim, and I voted for Kamala. Guess all those VS Code kids voted Trump.
learn Cobol you uneducated teenagers
SUBTRACT DATE FROM YEAR GIVING AGE.
It's all about WORKING STORAGE if you ask me.
tbf it's only embarrassing if you're capable of embarrassment.
But but it's BREAKING! With a red light emoji!
https://dev.to/mdchaney/cobol-dates-may-20-1875-and-disinformation-5ggh
That (obviously) doesn't mean Elon Musk is right. It just means that this explanation of it being some magical COBOL epoch value is wrong. What's more likely is that the Social Security database is very old and has a lot of iffy data in it.
My guess is that it contains everybody who has ever had a social security record, including all the duplicates, all the typos, and everything else. At some point there were probably hundreds of thousands of records that were transcribed from paper into a computer, and it was considered safer to keep the iffy data and make a plan to deal with it later, vs. remove someone from the database who should legitimately be there.
I would also imagine that the systems that take the records out of the DB probably have filters in place that remove the (known) bad records before they're used.
There is no "date" data type in COBOL, but there is in DB2, where the data would be saved, unless they are on an older VSE OS and data is still saved in VSAM files. Many still use 12/31/39 as a default max date even though OS/400 systems can handle up to year 9999 now (we still use 12/31/39 in testing where I work). It could be someone arbitrarily started using 1875, and others copied that.
Eejit...
As someone who is working on a project of recreating an enterprise application in a modern tech stack, the legacy code is hard to understand too.
We have something similar in that a ClaimClosedDate is defaulted to 01/01/1900 and if it has that date it means it’s not closed whereas now that would be a nullable field.
The question is, how do you not know the age of a recipient? I feel like that's kinda required to know, no?
There are many people who were born in developing nations during times of war who do not know their exact age. They usually do have an idea of a range though.
Ah, well that makes sense. Thanks for clarifying.
Jay Kuo is wirth worth following. I know people dislike substack, but a lot decent people publish there. Jay Kuo is good at breaking down the legal aspects of the mess we are seeing now
I'll wait until it get reposted on a platform that isn't doing revenue sharing with Nazis. You know, like myLemmy instance.
I share this sentiment, and I admit I am not entirly aware of the Substack situation tbh. The issue is that these people, often very good journalists need a platform that generates revenue for them. I am not American, but find that people like Kuo, Jennifer Rubin, Robert Reich and Joyce Vance give valuable insights on American politics, and "sound bites" that can be share. But they need lir financial support to do this.
They also found that there's people over 200, so that default date thing doesn't really explain it all.
It's because that explanation isn't correct. The real deal is you just have entries without a death date, so if you ran a query this get super old ages as a result.
Note that isn't a database of payments or even people eligible for them, just a listing of 'everyone' with a SSN. There is a separate master death index. In the old days, wild west kind of stuff people would disappear so the death date would never get entered. Modern days every morgue and funeral home has to legally notify SS when someone dies, there is a specific form and major hell to pay if you don't do it.
Social Security numbers were first issued in 1937. You would have need someone to be over 110 in 1937 to have an age over 200. I think that it's a combination of birthdays entered wrong plus no official death date.
Wouldn't matter anyway the ss admin automatically stops pay and initiates audit for anything over 115.
I think those are related to survivor benefits. Like an old man marrying a young woman in the 40's. Like the civil war vets marrying woman in the 20th century. The last civil war widow was getting benefits until she died in 2020. But still the same basic issue.
But in that case the old man isn't getting benefits but just is needed as a reference for the person actually getting them.
Also a lot of people between 110 and 150, so I'm sure there is a larger answer.
However, Social Security cuts off at 115, and they supposedly found like 10 million people older than that. Considering there are only ~50m people on Social Security, and the database they were searching wasn't even about current recipients, most people would conclude that there is likely an error in data, rather than immediately jump to fraud. Of course, ketamine is a hell of a drug and Elon is not most people.
It's definitely still concerning if the database has a large number of errors. But systematic fraud would be much worse ofc.
the database doesn't have to necessarily be accurate if there's other checks - a flag for test data, a system that checks the person is real against another database before dispersing funds etc
It's really funny to me that everyone thinks every database is always 100% correct. What a magical world it would be!
A minor grammar point: in this context, the word is actually "disbursing," from the same root as "bursar," a job title you may have encountered in school administrations. "Disbursing" means "paying out from a fund." "Dispersing" means "scattering" or "causing to dissipate." So the old system was disbursing funds. The new system will be dispersing funds.
That's true. Would be better if it was though.
Someone with the skills and knowledge to clean up 150-year old typographical errors in one particular table in the Social Security database system would probably provide more benefit to the taxpayers covering their salary by doing some other task.
How would you clean up that data? If they didn’t have the correct data in the first place, where do you expect to find it decades later?
Sometime real life is just bad data and that’s not necessarily a problem. All of the business logic and agency process around not spending money for those situations is probably one of the difficult areas blocking modernization or shrinkage. Bad data is reality. How you handle it shows how experienced you are
It might be better to move to a new database at this point rather than trying to fix the existing one. It won't give immediate benefits but could be helpful down the line.
Or it could cost a fortune and fuck a lot of other processes up.
I am hoping California ditches SSN and other identifiers from the US Treasury. That information is no longer safe, so we need a fresh database that is secure from DOGE fuckery, among many other hostile actors.
Fixing an archival dataset that doesn't even pertain to people actively receiving benefits is so far down the list of priorities as to be a criminal misuse if resources.
Lol why bring drugs into this? Specifically ketamine?
Because Musk is pretty open about his ketamine abuse
Ah. I see now. Thank you.
Isn't "embarrassing and dangerous" their whole strategy?
No one ever fucking lived to that age for fuck's sake!
Methuselah would like a word
In that case I think "year" means "lunar cycle". This makes a more natural age (80-something IIRC)
Maybe, but you don’t know that. You only know the data you have doesn’t make sense. You can’t just make something up and claim it’s correct: you have no way of knowing what the real data is , nor are you an authority
It’s probably logical to not pay out social security for 900 years, but that’s just an additional business process for handling bad data
I also have doubts about the correctness of the specific claim, but of course there’s bad data. How could there not be? That doesn’t mean you can claim fraud, it means you can check with the processes that keep money from being sent out where there is bad data.
I especially had a chuckle from the article where they said 90,000 claims are being sent out for people 100 yr old or more ….. yet the claim is that 10 million of those are fraud?
That's the"fraud" they supposedly found
i don't know shit from a sandwich and I know COBOL is old shit
now your hezlth records sare commodity
Conspiracy theory: They know this, but being able to claim to their followers, with official records to show for it, who know NOTHING about programming, is an easy, effective win for them. They can claim fraud to their gullible audience and now have records they can point to and say "LOOK! THEY'RE GIVING DEAD PEOPLE SOCIAL SECURITY MONEY!"
The response is wrong. I remember reading an article that disproved it and explained the actual reason. However I forgot the actual reason.
COBOL doesn't have a date type. And there were "people" in that "list" that weren't just 150 years old, and they varied in ages.
The real answer is that the list that they're saying is people getting social security, isn't the list of people getting paid, just lists of random ages in the database, which ultimately means nothing.
yeah I think they did a report on if it was worth updating the ages and found that there was no point. It would have been a waste of money.
The system obviously needs improvement and like it or not Trump and Musk are the first to actually try to improve it.
Musk just wants to dismantle any safety networks, so people will work for him for peanuts...
You do realize that what you are suggesting (Musk trying to destroy social security) just isn't what is happening in reality. Anyone that has been receiving SS still is, still receiving the same amount they historically have, and it has all been verified.
1875 has never been an epoch anywhere, on any system. 1970 has. 1900 has. 0000 has. But 1875? No, it hasn't. And no where in the cobol spec does 1875 appear.
This is just propaganda. He already does enough wrong, you guys lying about it just makes everything else you say suspect.
Apparently ISO 8601:2004 doesn't exist?
That doesn't mention 1875. Wikipedia was edited two days ago to add that in, it doesn't appear in the original standard at all.
https://www.iso.org/obp/ui/en/#iso:std:iso:8601:ed-3:v1:en
Not true, I picked a random revision of the Wikipedia article from October 2022, and it already had the part about 1875:
https://en.wikipedia.org/w/index.php?title=ISO_8601&oldid=1118165613
I'm pretty sure this has been in the Wikipedia article for even longer, considering that it dates back to 2001. I'm just too lazy to go through the entire history and check when it was added. But definitely not 2 days ago.
Edit: I also just googled "ISO 8601 2004", found this PDF: https://dotat.at/tmp/ISO_8601-2004_E.pdf
Under 3.2.1 "The Gregorian calendar" it says:
The Wikipedia article is correct, this wasn't added 2 days ago, and I don't know why you're spreading misinformation.
Another edit: A brief look at your profile explains everything...
Yet another edit: I checked the Wiki article using WikiBlame:
The part about 1875 was added to the article in 2004. Not 2 days ago. This is a blatant lie.
https://en.wikipedia.org/w/index.php?title=ISO_8601&oldid=4668168
Nowhere in the cobol spec because cobol doesn't even have a date type. It's more of a legacy solution to a nearly 100 year old problem.
Why is your profile picture a lemming? Nowhere in the rust spec does it say that a lemming should be the default picture. This is just propaganda.
"You guys are wrong about the epoch in COBOL and it's really making me believe this ketamine fueled Nazi, shame on you" lol you're ridiculous
I thought truth mattered right?
...right?
I was intrigued by this article as 1865 isn't any epoch I've heard about and I didn't think COBOL really had a concept of an epoch (an epoch matters when you're counting milliseconds from zero, COBOL stores date/time info differently). I've been searching this morning and can only find the Wikipedia page mentioning that date - which is weird for an ISO standard that is 99% about date formatting.
Yeah I've only heard of the 1970 epoch too, I didn't realise different languages had different epochs honestly! Interesting stuff. I've never worked with COBOL but my old boss was learning it a few years ago, it's used a lot in banking right?
That epoch is a Unix thing. It may not apply to systems not related to Unix.
It's used in mainframes mostly. I don't know COBOL well but I've worked with COBOL systems in the past. I didn't think it even has a "date type" (at least in older systems? maybe it was added at some point?). They just store dates as 8 digits (6 back in the day which led to infamous "y2k" problems). That's why I didn't think they had an epoch. In more modern systems a date is typically "the number of milliseconds since the epoch". For Linux that's 01/01/1970. Either way this explanation for Musk's error is pretty sus. I'm sure he's misunderstanding something (he didn't think the US government used SQL ffs) though.
Edit: It's possible this particular team used that date as some sort of special value. That would be pretty common in older programming styles. But it doesn't seem like it's any sort of "standard."
Why not focus on the Nazi bit? Instead of lying about the 1875 bit? Are you lying about him being a Nazi?
Am I lying? No, I don't know anything about COBOL and haven't said anything about it either.
A lot of people online are calling it a reference date, whatever that means. An epoch data doesn’t even make sense since there isn’t really a date time type. I can see reason to doubt, but that’s not relevant.
However it could be important to the app. Perhaps at some point they decided there needed to be a cutoff because anything older was bad data. OR perhaps back in the days where storage was extremely expensive it was important to save a byte for every row.
Even if the specific claim about 1875 is wrong, that doesn’t change anything. The reality is bad data exists, there doesn’t seem to be any indication of it being paid out, and the claim of fraud is assinine
Yeah that's not the defense you think it is.
Could you elaborate on why?
You shouldn't be using cobol in 2025
There are tons of IT systems in the government that have been running the same programming for 30+ years but if it isn't broke it doesn't get touched.
Source: Use mainframe emulators often to perform routine tasks in government HR systems.
Yeah that doesn't make it ok
Just in case you didn't know, the code is old, but the hardware still gets updates. And when it comes to batch transactions and network speed, mainframes still do the job reliably well. Plus, they are not easy to hack, because few understand them, not to mention the decades of security updates.
Mainframe does what it does very well, and that makes it okay.
The code may be old but the hardware gets updated. I don’t know if they’re using modern tools but the language also gets updated.
It alll comes down to budget: who wants to spend the money to modernize stuff that still works? Iss Musk willing to invest in that?
They would have to spend on new systems instead of giving tax breaks to corporate welfare queens and the landed gentry.
Money isn't the issue
Goober, they're gonna need to spend money on resources migrating away from it.
Elaborate as to what the specific issue is, please.
so the huge legacy codebase should be ported to....
and who's gonna do that? You?
The terrifying answer is that script kiddies will end up porting it to JavaScript and Electron and host it on AWS.
I wanted to write JavaScript first but decided against it :D
This hasn't been done because no one can do it. It's because the government sucks at this stuff
It hasn’t been done because that’s a great works project that’s on a scale you’re woefully ignorant to (this is an assumption on my part based on what I can grok of you based on your comments here).
I assure you there is a bevy of skilled developers who would love to modernize the systems they work on but the cost and level of effort is beyond what is politically viable.
If you changed your perspective from “it’s awful and bad and always will be” to “it’s awful and bad and we can make it better, how can I help” things will improve for everyone.
Mate, from reading the comments of this no-brains, he or she doesn't even know how to program in a professional capacity, much less have even the slightest clue of the scope of such a project.
That one is literally a mindless Trump/Elon fan wading into waters way, WAY, WAY beyond his depth.
I didn't say it wasn't big
I guarantee you that there are no governments, banks, or businesses older than 15 years that aren't running some old ass code that's not getting replaced any time soon.
Again that doesn't make it ok
Code is not a physical thing that spoils with age.
All that backs that sentence of yours is your uninformed opinion.
Good luck getting musk to pay to update the programs that most of the government uses.
These programs were written in COBOL, and they have had no reason to upgrade things that are still working.
Yeah having incorrect info isn't a reason to fix it, your right
You have to be one of Musk's adolescent DOGE cronies
This is the part everyone is missing. Real life is messy and sloppy and incomplete. Real life has bad data. All the time, especially when you’re trying to match 100 year old records. Not handling bad data s a problem of inexperience, regardless what technology you use. Announcing it as fraud, is just being an ignorant asshole.
That being said, if Musk is willing to put out the billions of dollars it would cost to modernize, that would be great! But it still has to handle bad data. Maybe musk could add hundreds of millions to the budget to hire enough people to manually confirm all the data from before the records were digitized. Good luck with that
If you want actual proof of this, look at your medical records. And I say this as a healthcare worker. All kinds of nonsense ends up in the chart for a myriad of reasons.
And that’s with modern record keeping where there are all safeguards and things are eventually digitized. Imagine the days when it was only on paper at some hospital where the records room was damaged in a flood or it wasn’t digitized for half a century so no way to check the handwriting, or the person had a strong accent or some dirt or mold fuzzed the paper, etc …..
I am one of the millions of people in the US whose name was fudged by immigration officials at Ellis Island. We know the name they wrote down and we have the family claim of what it used to be, by Mon objective way to prove it or to know why. To make this anecdote crazier, my parents went back to the old country to find records. However this was the height of the Cold War and it was behind “the iron curtain” so they were prevented from leaving their hotel under threat f arrest as spies
Yeah, great. Is DOGE going to fix any of that?
Probably
That's a delusional answer.
How
The only possible way DOGE would eliminate that code is if the agency doesn't exist anymore.
Yes, it is defending cobol. Otherwise it would say this is bad and needs to be fixed
Are you actually Elon Musk trying to gaslight all of us?
No
What an incredibly boring troll you are.
You could at least put some effort into it. Back in the days we would at least get the Marine Copypasta or something.
...not. probably not. That's what you meant to say. Right? Right??!!
No
Well don't worry. You're allowed to change your mind at any point in time once you realize the mistakes you've made regarding the trust and belief you've put in these people.
Lolololol tell that to literally every major bank, I'm sure they'll get right on it just for you.
How much experience do you have in this? Talk is cheap
If relying on any knowledge is bad, then why should we believe what you say? That's an appeal to authority
Why should anyone listen to what you have to say? Can you give a reason without an appeal to authority?
So spend a chunk of money to hire a team to upgrade the database that's working to one that's programmed in a new language,
mightwill have errors, then have to fix those errors, and you'd also have to train the existing team or replace them with someone who knows how to use and maintain the new database. You'd potentially want to upgrade or change the hardware too from an old mainframe computer unless you want to only sidegrade to like C-90 since your old IBM computer won't support newer compilers. In the meanwhile there's a HUGE risk of breaking something or even just not getting anything accomplishedIt's definitely an objective that's good but if you're chasing efficiency and cutbacks, it's the opposite of what you'd want to do.