> COBOL — a language taught in fewer than 25% of colleges a decade ago.
Yes, fewer than 25%, I'm sure. Probably more like fewer than 10% of colleges 25 years ago.
Really though, I'm not totally convinced that you need to know COBOL (beyond some vague sense of being able to kind of get the gist) if you are going to rewrite everything from scratch. That's not to say that I think they'll be successful. The time is too short, the tolerance for errors is too small, and their attitudes are just not compatible with getting things right.
Yes, this screams really hardcore requirements gathering and starting from scratch - you really don't need to know the existing code, you need to know what it does and what people expect to have happen when they do something. Just rewriting the COBOL into something modern would be silly. For example, I had a system that had been created before you could do global searches across many fields, and so it was set up so you had to search each field individually - HAD TO, not had an option to. No need to keep that functionality in a modern system.
The thought of doing requirements for a system this complex is giving me an instant headache.
I suspect you really *do* need to know the existing code.
from ZDNet:
“a lack of documentation, and inconsistent standardization make understanding and porting these systems difficult. To add to the complexity, legacy COBOL applications often contain business logic and processes intricately woven into the code.”
Good programming (at least as I was taught, admittedly some decades ago) includes comments, i.e. documentation, in the code. If you’re staring at code trying to understand it, it helps a lot to have the explanation *right there*, and not have to jump backwards and forwards between the code and another document.
Imagine an underfunded, understaffed IT team; they’ve just slogged through a project to update or add a module, are they going to sit down and fully document all the logic, or is someone higher up the chain going to push them onto the next job on the backlog? A lot of the old documentation, if it exists; will be on paper, filed—somewhere—not searchable, and maybe even cataloged on paper.
I suspect that any serious, thoughtful, effort would want to be prepared to work from both directions but in principle you wouldn't necessarily need to know more about the old system than is required to pull data from it:
The system was set up to help the SSA execute its legislated and administratively-defined obligations, which are ultimately the canonical system(with the actual biographical and pay-in data stored on the system mandatory for knowing what those obligations are and how to fulfill them in detail, dollar amounts, addresses, etc.); so while it is probably the de-facto authority in places where legislation or policy were not entirely unambiguous(since the programmers needed to build something that arrived at a definitive result; while legislation and administrative policy do not get validated at compile time); in theory you could build a totally separate system based on the requirements that were used to build this one then bring the data over.
I would not advise doing it that way; but in theory this is a case(unlike software preservation type efforts) where the old system is not actually canonical and it was built to requirements that exist elsewhere; though it almost definitely has valuable insights for anyone seeking to build a new one; and the existing data is canonical.
Yes, requirements are in statute, regulation, as well as court and administrative decisions. Of course Elon tends to take a "So sue me," attitude to the law. The other difficulty with the doge bros seems to be not understanding exactly how the existing data is encoded.
It's always so interesting working with regulations. Right now I am working on a system to do food establishment inspections. And there are the regs, the interpretation of the regs, and then the way the state looks at the regs and goes, oh, crap, no one's going to understand this mess. For example, the regs say X, Y, and Z and if someone messes up that part of the regs, we are supposed to quote the code section of the reg in the inspection report. But then the state realized that the regs are not in layman's language, so now they don't want us to quote the actual reg but to make up some version of it in layman's terms. But the team is hesitant to do that on their own, because what if the piece that seems most important to them is different than what the state wants to emphasize? And the regs say that if an establishment has to be reinspected 4x in one year, they should be automatically closed, but when we met with state representatives they said, oh no wait, that's more to your discretion even though the regs say to close. Regulations always sound like they should be nice, neat rules to follow to the letter T, but then turn out to be a bit more squishy.
Is the area you are in aided (and/or plagued) by the layer of consultants that certain regulations attract?
I'm mostly Ops in a small enough environment to sit within hearing distance of Apps and Quality, rather than specifically either of those; but at work I've been struck by the difference between FDA GxP stuff (basically all handled in-house by Quality and Regulatory according to statute and industry guidelines) and when we looked at (but did not ultimately pursue, farming it out was a small price to pay) PCI compliance; which is theoretically a set of written standards that you just meet, albeit contractual rather than legal; but absolutely rotten with random consultancies all promising to be experienced auditor-whisperers who know the real secrets of what does and doesn't truly matter to the payment card industry.
Since we ended up not dabbling in first party payment processing it ended up not being an ongoing issue(though we retained some of the more intuitively sensible advice as ammunition for all the times someone thinks they'll make something work fast and easy by just exposing SQL to the entire network because what could go wrong? but the cultural difference between the FDA GxP process and PCI was just so striking that it left me wondering how large the range of compliance cultures actually is.
Certainly, if the code is well-documented, that would be great. I've not worked with many systems where the code is well documented. Some devs are great, some comment not at all, and a system this old is sure to be quite Frankensteined.
One thing I have found ChatGPT to be useful for is to take old code (albeit, not COBOL) and drop it in there and ask ChatGPT to add comments. Even with decently commented code it can be helpful. I doubt ChatGPT can comment COBOL, though.
Gotta hope there's at least one IT person left there that would make a good rollback plan for when the code blows up in everyone's faces. How much do you want to bet the DOGE kiddies don't like to test?
Stories from other agencies suggest that the kiddies test by putting new code into production and seeing what happens. "Fail Fast" and all that. Doing it right would mean several cycles of parallel runs old and new, but that would be expensive and time-consuming. :-|
Given the odds that this is a pillaging job we are probably hoping that some hero is risking prosecution for squirreling away some off-the-books backup tapes that DOGE is kept from knowing about; not merely ensuring that backups are being competently run.
After all; it's destroying the existing SSA system that, by definition, implies that your rewrite is the SSA system, not test outcomes or UAT or any similar 'legacy' considerations.
And they want to do this why? Because they don’t understand code written before they were born? Can someone please yeet all of them into the sea already?
# ...a question of whether our social security system fails along with it.
.
Everyone knows the Mantra:
"Government can't do *anything* right" and what better excuse to privatize it than by *ruining* it?
Usually, they defund a program they don't like (public education, for one), enough so that it *can't* effectively function, then point to the shiny, new, *privately owned* program just coincidentally waiting in the wings as a solution.
What I'm morbidly curious about is which type of ticking time bomb it will end up being.
Classical Republican war on social security would be a straightforward movement of the money into the financial services sector for people who do actually pay in amounts worth stealing; with some kill-the-poor handling of the support programs that the SSA administers but which are legally distinct.
A Trump execution of social security, though, seems like it might not be as finance oligarch focused. It will absolutely be oligarchical; but seems much more likely to, say, include the use of voter registration and demographic data to use the (remaining) public services to reward loyalists and deprive the opposition. Chavismo with fascist characteristics(maybe with some creepy 'pro-natalist' contributions from Vance and pals); rather than a strict focus on ensuring that social security all gets rolled into 401ks so that the fund managers get their cut.
> COBOL — a language taught in fewer than 25% of colleges a decade ago.
Yes, fewer than 25%, I'm sure. Probably more like fewer than 10% of colleges 25 years ago.
Really though, I'm not totally convinced that you need to know COBOL (beyond some vague sense of being able to kind of get the gist) if you are going to rewrite everything from scratch. That's not to say that I think they'll be successful. The time is too short, the tolerance for errors is too small, and their attitudes are just not compatible with getting things right.
Yes, this screams really hardcore requirements gathering and starting from scratch - you really don't need to know the existing code, you need to know what it does and what people expect to have happen when they do something. Just rewriting the COBOL into something modern would be silly. For example, I had a system that had been created before you could do global searches across many fields, and so it was set up so you had to search each field individually - HAD TO, not had an option to. No need to keep that functionality in a modern system.
The thought of doing requirements for a system this complex is giving me an instant headache.
I suspect you really *do* need to know the existing code.
from ZDNet:
“a lack of documentation, and inconsistent standardization make understanding and porting these systems difficult. To add to the complexity, legacy COBOL applications often contain business logic and processes intricately woven into the code.”
https://www.zdnet.com/article/if-cobol-is-so-problematic-why-does-the-us-government-still-use-it/
Good programming (at least as I was taught, admittedly some decades ago) includes comments, i.e. documentation, in the code. If you’re staring at code trying to understand it, it helps a lot to have the explanation *right there*, and not have to jump backwards and forwards between the code and another document.
Imagine an underfunded, understaffed IT team; they’ve just slogged through a project to update or add a module, are they going to sit down and fully document all the logic, or is someone higher up the chain going to push them onto the next job on the backlog? A lot of the old documentation, if it exists; will be on paper, filed—somewhere—not searchable, and maybe even cataloged on paper.
I suspect that any serious, thoughtful, effort would want to be prepared to work from both directions but in principle you wouldn't necessarily need to know more about the old system than is required to pull data from it:
The system was set up to help the SSA execute its legislated and administratively-defined obligations, which are ultimately the canonical system(with the actual biographical and pay-in data stored on the system mandatory for knowing what those obligations are and how to fulfill them in detail, dollar amounts, addresses, etc.); so while it is probably the de-facto authority in places where legislation or policy were not entirely unambiguous(since the programmers needed to build something that arrived at a definitive result; while legislation and administrative policy do not get validated at compile time); in theory you could build a totally separate system based on the requirements that were used to build this one then bring the data over.
I would not advise doing it that way; but in theory this is a case(unlike software preservation type efforts) where the old system is not actually canonical and it was built to requirements that exist elsewhere; though it almost definitely has valuable insights for anyone seeking to build a new one; and the existing data is canonical.
Yes, requirements are in statute, regulation, as well as court and administrative decisions. Of course Elon tends to take a "So sue me," attitude to the law. The other difficulty with the doge bros seems to be not understanding exactly how the existing data is encoded.
It's always so interesting working with regulations. Right now I am working on a system to do food establishment inspections. And there are the regs, the interpretation of the regs, and then the way the state looks at the regs and goes, oh, crap, no one's going to understand this mess. For example, the regs say X, Y, and Z and if someone messes up that part of the regs, we are supposed to quote the code section of the reg in the inspection report. But then the state realized that the regs are not in layman's language, so now they don't want us to quote the actual reg but to make up some version of it in layman's terms. But the team is hesitant to do that on their own, because what if the piece that seems most important to them is different than what the state wants to emphasize? And the regs say that if an establishment has to be reinspected 4x in one year, they should be automatically closed, but when we met with state representatives they said, oh no wait, that's more to your discretion even though the regs say to close. Regulations always sound like they should be nice, neat rules to follow to the letter T, but then turn out to be a bit more squishy.
Is the area you are in aided (and/or plagued) by the layer of consultants that certain regulations attract?
I'm mostly Ops in a small enough environment to sit within hearing distance of Apps and Quality, rather than specifically either of those; but at work I've been struck by the difference between FDA GxP stuff (basically all handled in-house by Quality and Regulatory according to statute and industry guidelines) and when we looked at (but did not ultimately pursue, farming it out was a small price to pay) PCI compliance; which is theoretically a set of written standards that you just meet, albeit contractual rather than legal; but absolutely rotten with random consultancies all promising to be experienced auditor-whisperers who know the real secrets of what does and doesn't truly matter to the payment card industry.
Since we ended up not dabbling in first party payment processing it ended up not being an ongoing issue(though we retained some of the more intuitively sensible advice as ammunition for all the times someone thinks they'll make something work fast and easy by just exposing SQL to the entire network because what could go wrong? but the cultural difference between the FDA GxP process and PCI was just so striking that it left me wondering how large the range of compliance cultures actually is.
Certainly, if the code is well-documented, that would be great. I've not worked with many systems where the code is well documented. Some devs are great, some comment not at all, and a system this old is sure to be quite Frankensteined.
One thing I have found ChatGPT to be useful for is to take old code (albeit, not COBOL) and drop it in there and ask ChatGPT to add comments. Even with decently commented code it can be helpful. I doubt ChatGPT can comment COBOL, though.
Gotta hope there's at least one IT person left there that would make a good rollback plan for when the code blows up in everyone's faces. How much do you want to bet the DOGE kiddies don't like to test?
Stories from other agencies suggest that the kiddies test by putting new code into production and seeing what happens. "Fail Fast" and all that. Doing it right would mean several cycles of parallel runs old and new, but that would be expensive and time-consuming. :-|
Given the odds that this is a pillaging job we are probably hoping that some hero is risking prosecution for squirreling away some off-the-books backup tapes that DOGE is kept from knowing about; not merely ensuring that backups are being competently run.
After all; it's destroying the existing SSA system that, by definition, implies that your rewrite is the SSA system, not test outcomes or UAT or any similar 'legacy' considerations.
And they want to do this why? Because they don’t understand code written before they were born? Can someone please yeet all of them into the sea already?
Failure *is* the goal.
# ...a question of whether our social security system fails along with it.
.
Everyone knows the Mantra:
"Government can't do *anything* right" and what better excuse to privatize it than by *ruining* it?
Usually, they defund a program they don't like (public education, for one), enough so that it *can't* effectively function, then point to the shiny, new, *privately owned* program just coincidentally waiting in the wings as a solution.
.
This is a ticking time bomb.
What I'm morbidly curious about is which type of ticking time bomb it will end up being.
Classical Republican war on social security would be a straightforward movement of the money into the financial services sector for people who do actually pay in amounts worth stealing; with some kill-the-poor handling of the support programs that the SSA administers but which are legally distinct.
A Trump execution of social security, though, seems like it might not be as finance oligarch focused. It will absolutely be oligarchical; but seems much more likely to, say, include the use of voter registration and demographic data to use the (remaining) public services to reward loyalists and deprive the opposition. Chavismo with fascist characteristics(maybe with some creepy 'pro-natalist' contributions from Vance and pals); rather than a strict focus on ensuring that social security all gets rolled into 401ks so that the fund managers get their cut.
>…kill-the-poor…
.
Put ‘em to work doing the jobs the immigrants used to do.
Work ‘em till they drop, then into the trench they go.
Imagine the savings in food, housing, and medical care!
And more money in Lord Dampnut’s pockets!
.
>…reward loyalists and deprive the opposition.
.
Of course, with Lord Dampnut, loyalty only works one way.
Then, see step 1 above….
It’s best not to be too optomistic, nowadays.
Correction: Musk's [INSERT HERE] plan is "profoundly stupid and will definitely fail" says expert.