I was sort of tempted to pursue this. I did a few years in the salty COBOL mines back when I was a PFY about 20...plus years ago. This niche probably hasn't moved very much since then and I could probably recall most of it after a few hours. I'm freelancing right now anyway and some other projects just vaporized.
But.
A quick skim of the postings is finding that what they're really screaming for is somebody who's been familiar with their particular pile of toxic waste for at least four years at minimum. They're asking for people with 4+ years of COBOL, and JCL (ok, fine), and DB2, and VSAM, and "SDLC" (proto-waterfall), and, oh yeah, a four-year degree.
Heck, there's a posting asking for somebody to draw diagrams and document their existing processes, and for that they expect you to have 10 years of COBOL experience.
Okay then. This is not yet a mess that they're motivated enough to fix.
Or they, like many non-technical organizations, have no idea how to hire programmers. Could be worth a shot; even at regular companies they often over-state resume requirements.
As someone who works with a lot of state IT people, if they don't know how to hire programmers, they probably don't know how to manage programmers. In a bureaucracy, if the administrators are making these kinds of unrealistic hiring demands in a crisis, it probably means that the administrators outrank all programmers and don't trust them to make their own decisions. This is not an environment to work in.
Yes, they hired a 24 year old college grad into personnel and she/he copied some old specs used by companies that wanted to bring in H1b programmers from off-shore.
The job specs were 40 lines long and pay was $60,000 a year for 10 years experience.
Then there were the places that brought in consultants that were doing a big rewrite, ignored the local staff and impressed management with their dark blue suits and white shirts, and left 6 years later without the project done.
During that time the best of their own programmers left and they were left with the dregs and those a few years from retirement.
Thought about doing this but I remember how we were treated. I left a job like that in Texas, worked in a shop in Connecticut with a room full of empty cubicles, and one very old guy and one new hire who knew Access.
Even the Director of MIS was being cut there but allowed to stay a few more months to apply for other jobs without saying he was unemployed.
So what if they don’t know how to hire programmers? All they have to do is hire someone who has had engineering leadership role/experience and let them hire programmers, isn’t it?
Isn’t it easier to verify someone’s leadership credentials than COBOL skills?
I can tick the 10+ years COBOL box nicely, though that was 30+ years ago and with that, somebody with 1-3 years COBOL would be more effective than somebody as myself.
Still, in an era of movie superheroes, who knew that having 10+ years upon your CV would enable you to go, step aside good citizens, for I shall save you. COBOL man to the rescue.
Don’t be surprised if this position then goes to an H1B contractor though.
If enough anericans who have this knowledge do not apply because they
- Hate the tech
- Can’t provide their feedback to improve the system
- Don’t like the salary offered even if’s greater than their current unemployment income,
then is it for an offshore company to come in and fill that gap.
I don't think the point is that Americans should consider themselves too good for the COBOL jobs. The point is that the organization has stated that it will refuse to hire many people who would be willing and able to do the jobs.
And that's why most American programmers hate H1B. It's not about filling jobs that we don't have the skill for, it's about filling jobs that companies don't want to spend money on. Offer a half mil a year, and watch how many qualified Americans come out of the woodwork.
Which popular H1B source countries teach COBOL? I feel like the advent of cheap offshore programming came well after the decline of COBOL. Though my sense of history can very well be off.
If you get an S0C7, your JCL is probably fine (else you wouldn't get far enough to get a data exception).
JCL is just another scripting language. I found it fun. I did all the JCL for my group's production jobs and commented the hell out of the esoteric issues to help Operations triage things. A small, well-planned effort prevented a crapload of, well, crap.
SDLC is often used to emphasize that you need to be familiar with the full "Software Development Lifecycle".
When I read SDLC I just assume they mean, "you need to be able to take a project from concept to deployment (including documentation for supporting it long term)".
Depending on org structures, a lot of engineers only work on one part of that pipeline throughout their career.
In the mid-80s, my first year CS professor anticipated most us ending up "in the lead mines of COBOL programming" — it was commonly assumed that we'd never manage to get rid of the dominance of COBOL.
Are references to mining common in the COBOL scene?
For me the exact opposite. 15 years ago I removed any and all reverence to my history of COBOL because I was suddenly actively being contacted for COBOL coding jobs.
Although I had a great time, as a starting coder, with COBOL jobs (transcoding COBOL to C at the time), I know one thing: ever ever again will I utter one like of COBOL code.
There are still people making very decent money doing it, but the lockin to one particular source of work just does not sound like what I could bare.
dont really know anything about this particular case, but:
Isn't it common for job applications like this to state what they "want", even if they know that it doesn't exist? (such as 3 years of experience with an 1 year old product).
Then they just hire the person who gets the closest to what they want.
4-year degree? So that rules out Bill Gates, Larry Ellison, Michael Dell, Mark Zuckerberg.
To get serious, they need to move HR aside. Many of the best techs from the '70s and 80s dropped out of college. What was called for back then was real-world experience, not slips of paper.
I seem to spend most of my working life trying not to embarrass people with 4-year degrees who can't even spell things like "COBOL".
Techies: What can we do to help? 3D print ventilators? Process terabytes of data in seconds? AI?!
Govt: We need COBOL programmers.
Techies: I am powerless to help.
But seriously some of the brightest techies I know quit their jobs to do a stint of government work which included slinging VBA and ASP Classic to remove SQL injections from VA websites and other similarly unglamorous tasks with huge impact.
If you want to be patriotic. If you want to make a difference. Government work can do that. You're probably not going to train a neural net to solve coronavirus, but you'll probably be able to stop 1000 hacks from ever happening or get help to someone who really truly needs it.
Imagine making even a minor change to the COBOL code. It's not likely to be very well structured or comprehensible. I'm guessing there would be a lot of global variables and strange database / file system interfaces. Very hard to do it without breaking something somewhere.
Edit: per the thread starting with vaidhy's comment.
> If you want to be patriotic. If you want to make a difference.
And continue to incentivize politicians (and their voters) to underpay employees and delay infrastructure spending until a crisis, and then beg for more “patriotism”.
People are asking "Can I bring my comparative advantage to bear?" because obviously the best way I can contribute if I were making half a million dollars is to take $50k of my post tax income and allocate it to boosting the salary offered.
you make relieveing the government of its social obligations so it can do more wars / interventions / bailouts sound like it has some kind of humanitarian dimension...
Governments are made by people, of people, and for people. If you disagree with how the US government functions the answer is to get more involved, not less.
Slinging COBOL for New Jersey is not going to drop more bombs in Syria, but it might just save some lives by managing government operations more efficiently in a moment when every hour and dollar counts.
I used to work on mainframe COBOL during the Y2K times. While the language is easy to pick up and the OS specific things are not too hard, the style of programming can lead to issues. Typically, shared data structures are often stored in separate files called copybooks and they can be hard to track down. Most of the code is not in any source control repositories which means no one knows which is the actual deployed version. It was all fun times then..
Site standards would play a huge part, you can write code without using GOTO in COBOL fine, and some programmers loved JSP (Jackson Structured Programming), yet modifying that code would make things open to whoever modified it and so the nuances and quirks of the programmer play out and code that has had many years of evolving standards and programming styles can be a right nasty mess that always begs a rewrite but the budget is for the change and no time for the rewrite. So the legacy snowballs.
Hence not all code equal and the site standards and that history as well as knowing that can make an almighty difference.
Never had copybook issues with ICL or Honeywell BULL platforms ;). That would be an IBM thang, but then, is there anything else still running - probably.
Usually you just compile the code to get the copy books. Ezpz. But yes its common practice in my office to carry a thicc black binder around for each companies’ copy book.
I’m newer to the mainframe industry but not that new and I’ve never seen a place that doesn’t have a source control repository. In fact, it’s required by law in every company I’ve worked for.
This is all second-hand, etc., but from what I've heard, NJ's IT systems are a mess across the board.
The most shocking story was about their system for tracking Medicaid patients. Their system had a fixed-width field for the patient's ID, and they ran out of identifiers - so they just started to recycle them again from the beginning. This problem was multiplied by the fact that, to say money, they didn't have backups of the original, clean data before the recycling. Thus it became pretty much impossible to understand what benefits had been afforded (or not) to whom.
Governmental budgeting seems biased strongly in favor of labor expenses, especially those with seniority, to the detriment of the maintenance of capital assets. This is pretty much a recipe for technological debt.
Any state government it department is going to be a royal mess. I worked for the Washington state government for 6 months a few years ago and it was the worst job I’d ever had.
I was at the top of my pay grade just under architect and only two years out of college making around 68k a year in Olympia. Olympia is not a cheap place to live. On top of that you’re basically legislates NOT to do work.
This issue highlights one of my main fears about a pandemic such as COVID-19: if enough people with the necessary amount of knowledge to maintain necessary infrastructure die without sufficiently and timely trained replacements, then civilization as we know it becomes one more step closer towards total irrecoverable collapse.
The prevalence of COBOL and other older programming languages in many parts of the world's critical infrastructure (unemployment claims here, finance, government, defense) means that the average age of someone maintaining these systems tends older. Older people tend to have more health issues. From the summaries of reports I read about COVID-19, the majority of the deaths happen among the elderly and those with other health conditions.
The idea of civilization collapsing might seem fanciful and farfetched, but the idea struck me after watching a video that was submitted here on HN and the videos it references [0][1][2][3].
Jonathan Blow has a point that we cannot assume things will keep getting better. Although he says that we cannot fix software because we have chronically not done it for decades, his thesis is that the solution is to make software simpler. The issue I have with making things simpler is that if we don’t know how to fix things because we haven’t done it for decades, how can we make things simpler, when we haven’t done THAT for decades either? His argument rejects human exceptionalism, while also relying on it for his solution.
My point is that this absolutely is a funding and priority issue. I work as a developer who maintains legacy FORTRAN code. It was written in an era where global variables and Go To statements were the norm. Everyone who wrote it is retired or dead. It’s a pain to work with and there are parts that I haven’t yet gathered the courage to go in and change. However, me and my team have made substantive changes to it that are robust, that we have rigorously tested. This is not impossible, but it’s also not cheap or fast. It took me a year to understand how this blob of code works.
My team is young, we’re in our 20s, with backgrounds in CS, mechanical engineering, and physics. Certainly all systems are different, but if we can understand old FORTRAN, similar people can understand old COBOL. If people made it, people can understand it. We also know how to fix many broken things and how to fix many bugs. Often were told by management “not right now” and “we don’t have funding for that.” It’s frustrating, but that’s how the world works. They at least have funding to pay us to do what we’re doing now.
The point is that you can fix legacy systems, you can hire new people to do it, but it is expensive and it takes time. The whole issue is not whether we can or can’t, we can. The issue is: who can pay for it and will they?
This is a very hard problem. Not a silver bullet but I’ve often found that metrics are the best way (again not guaranteed) to get the money (wo)men on board. If you can demonstrate concretely how the legacy code affects your operational readiness or agility, it might make it a better sell to invest in refactoring. However the lack of standard tools to do this is a problem.
The problem with code is that most non technical companies don’t have a clue how this thing works. They use analogies. And for most folks the analogy is that of a machine that once built never breaks down. If you can demonstrate viscerally how bad the system is, it can help get better support.
For all of these large, old organisations that still use COBOL, the risk isn’t that they run out of COBOL engineers to hire. COBOL is a very simple programming language, it was designed to be as simple as SQL. SQL was designed to be so easy that non-programmer business analysts could use it, COBOL was designed to be the same thing, but for non-DB business logic. Though you could debate how successful either of them were.
The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble.
Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration.
> The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.
Many generational skills die out. Your grandparents would make their own butter, bread, many things today that are not so common. Then more, many skills lost over time and fact we are still working out some historical things got created, you can imagine rosetta code sites being a good thing to keep alive for the future. http://rosettacode.org/wiki/Rosetta_Code
The difference you're missing is we're still relying on COBOL, but we aren't relying on grandparents to make the butter and bread we eat lest we starve.
> Your grandparents would make their own butter, bread, many things today that are not so common.
I've never made butter, but I have used raw milk. And I've failed at whipping cream, by overdoing it. So from what I've seen, "making butter" is basically just agitating cream until the fat clumps, and then pressing out the whey.
Making bread, I admit, takes more skill.
My mother knew how to make blood pudding. But that's not something I miss very much.
Given enough time I'm sure we can figure it out. The problem is that they're not looking for archaeologists, they're looking for people who lived among the dinosaurs.
Like Gibson's remark about the future already being here but not evenly distributed, the collapse is already happening but unevenly distributed.
Puerto Rico was without electricity for months. Some parts of the West will recover from the economic effect of the pandemic quickly. Others won't, without help from the center.
> then civilization as we know it becomes one more step closer towards total irrecoverable collapse.
I love how pop culture always portrays the collapse as coming from our inability to maintain or repair some mythical machine or technology. Never once did I imagine that it was the state welfare software.
This will sound weird, but they should call up Northwestern State University of Louisiana for an alumni list. They were one of the last 4-year places that had a COBOL-focused degree program, through to at least 2012.
I whole heartedly agree. The problem with government tech positions is they are not even competitive. Instead of hiring three mediocre or less than mediocre engineers at $60k, why not hire an amazing $150k - $180k engineer? I’m pretty sure they have ceilings on positions just so people don’t get outraged at government salaries, but incidents and times like these prove government needs to be competitive with private business to attract talent. Especially in national security and healthcare roles.
About ten years ago I worked for a consulting company that did lots of work for our state government. One particular state agency wanted to hire me to maintain the system we built for them but it would have been a nearly 50% pay cut. The only people they were able to hire on that pay scale were those who moved on the first chance they got from the private sector. Each time they'd end up giving us a contract to take care of things during the interim period and then train whoever they hired. Went through three cycles of that until I changed companies. Who knows, maybe they're still going through cycle after cycle of hire, programmer leaves, big contract the consulting company, train new person to take over. There's no way it was cheaper than just paying someone the going open market rate but the state pay schedule for that job classification simply won't allow it.
I have a pipeline of good to great engineers wasting time in NJ State Universities and Govt agencies moving into my company. Great hunting grounds for people who can grow.
A little better than that, though not Google salaries. Skimming through some open NJ civil service jobs, I'm seeing advertised ranges like $60k-$105k for tech jobs [1] [2]. The pensions are also a lot more generous than most private-sector ones.
If you’re valuing an NJ government pension at more than $0 to be received more than 5 to 10 years from today, you’re in for a rude awakening.
Maybe $0 is hyperbole, but there is no chance NJ makes good on all of its defined benefit pension promises, and I would rather just get all cash/401k as compensation.
The point at which the government should have rewritten their COBOL systems into a language that would have a talent pool to draw from was at least 30 years ago.
This feels like government thinking around infrastructure or military hardware where you open up bids and accept the lowest offer.
While there are problems with lowest-bidder-win, the real issue here is that systems like this are more living and breathing than one-off; you need a teams that tend to them, not bringing in a contractor.
Needs a design-build contract, like the Highway 99 tunnel in Seattle. You get one set of money and only if it works in the end. No change orders or cost plus.
> The point at which the government should have rewritten their COBOL systems into a language that would have a talent pool to draw from was at least 30 years ago.
Lack of foresight, lack of understanding that codebases are a living thing and are never "done". But hey, let's all work for ad companies and put our best minds at solving how we could make people see more ads!
Isn't it the power of the executive branch to requisition corporations or people in time of deep crisis in order maintain the continuity of government and its critical systems? Isn't unemployment claims such a critical system?
UI is mostly federally funded so they need to coordinate with them, and the complexity of the business rules and minimal funding during good times makes it a difficult task.
Also these systems generally work well, and it’s hard to fix things that aren’t broken. They just cannot handle the never before seen volume — it’s unlikely that a more modern enterprise system would either.
>>it’s unlikely that a more modern enterprise system would either.
sorry but that is just false. a Properly designed modern system would handle horizontal scaling just fine.
Granted the government would likely pay a billion dollars to have a screwed up system developed by on of the "big guys" that has the same problems as they current system, most likely because it would be designed by committee and not by engineers.
However to say that modern systems could not handle this kind of problem is just wrong. There are all kinds of ways to handle a sudden increase in load.
In SF permitting/entitlement system is being rewritten for already 5 (8?) years. Funding is only ~1M, while this is an easy task such small budget for for 5 years of work does not worth it even if you can build this by a single developer.
Readit News
But.
A quick skim of the postings is finding that what they're really screaming for is somebody who's been familiar with their particular pile of toxic waste for at least four years at minimum. They're asking for people with 4+ years of COBOL, and JCL (ok, fine), and DB2, and VSAM, and "SDLC" (proto-waterfall), and, oh yeah, a four-year degree.
Heck, there's a posting asking for somebody to draw diagrams and document their existing processes, and for that they expect you to have 10 years of COBOL experience.
Okay then. This is not yet a mess that they're motivated enough to fix.
The job specs were 40 lines long and pay was $60,000 a year for 10 years experience.
Then there were the places that brought in consultants that were doing a big rewrite, ignored the local staff and impressed management with their dark blue suits and white shirts, and left 6 years later without the project done. During that time the best of their own programmers left and they were left with the dregs and those a few years from retirement. Thought about doing this but I remember how we were treated. I left a job like that in Texas, worked in a shop in Connecticut with a room full of empty cubicles, and one very old guy and one new hire who knew Access.
Even the Director of MIS was being cut there but allowed to stay a few more months to apply for other jobs without saying he was unemployed.
I left.
Isn’t it easier to verify someone’s leadership credentials than COBOL skills?
Still, in an era of movie superheroes, who knew that having 10+ years upon your CV would enable you to go, step aside good citizens, for I shall save you. COBOL man to the rescue.
https://en.wikipedia.org/wiki/Grace_Hopper
https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
If you see any bosses with a weird scarf, back away cause they may spit corona-acid in your face!
1. understanding the language (COBOL)
2. IBM mainframe experience (JCL, DB2, VSAM, SDLC)
3. credentialed (4-year degree)
Note that SDLC is a layer 2 network protocol in the SNA stack:
https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control
Why do you need to pay a college to get a piece of paper to enable someone to pay you for skills you otherwise posses?
If it referred to SNA, it should be SNA/SDLC. Not referencing that (or VTAM) means Software Development Life Cycle.
(The auction would also give politicians a nice incentive to find ways to increase the revenue received.)
Deleted Comment
About the only other thing I remember is:
No. Thank. You.JCL is just another scripting language. I found it fun. I did all the JCL for my group's production jobs and commented the hell out of the esoteric issues to help Operations triage things. A small, well-planned effort prevented a crapload of, well, crap.
Deleted Comment
https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control
In the mid-80s, my first year CS professor anticipated most us ending up "in the lead mines of COBOL programming" — it was commonly assumed that we'd never manage to get rid of the dominance of COBOL.
Are references to mining common in the COBOL scene?
https://en.wikipedia.org/wiki/Salt_mining#Idiomatic_use
For me the exact opposite. 15 years ago I removed any and all reverence to my history of COBOL because I was suddenly actively being contacted for COBOL coding jobs.
Although I had a great time, as a starting coder, with COBOL jobs (transcoding COBOL to C at the time), I know one thing: ever ever again will I utter one like of COBOL code.
There are still people making very decent money doing it, but the lockin to one particular source of work just does not sound like what I could bare.
Isn't it common for job applications like this to state what they "want", even if they know that it doesn't exist? (such as 3 years of experience with an 1 year old product).
Then they just hire the person who gets the closest to what they want.
To get serious, they need to move HR aside. Many of the best techs from the '70s and 80s dropped out of college. What was called for back then was real-world experience, not slips of paper.
I seem to spend most of my working life trying not to embarrass people with 4-year degrees who can't even spell things like "COBOL".
Govt: We need COBOL programmers.
Techies: I am powerless to help.
But seriously some of the brightest techies I know quit their jobs to do a stint of government work which included slinging VBA and ASP Classic to remove SQL injections from VA websites and other similarly unglamorous tasks with huge impact.
If you want to be patriotic. If you want to make a difference. Government work can do that. You're probably not going to train a neural net to solve coronavirus, but you'll probably be able to stop 1000 hacks from ever happening or get help to someone who really truly needs it.
Edit: per the thread starting with vaidhy's comment.
If you thought that was exciting I can't imagine hacking on archaic COBOL codebase could be much worse in terms of quality of tooling!
There's also a much better chance you'll have a say in the replacement if you work on and understand the original.
And continue to incentivize politicians (and their voters) to underpay employees and delay infrastructure spending until a crisis, and then beg for more “patriotism”.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Slinging COBOL for New Jersey is not going to drop more bombs in Syria, but it might just save some lives by managing government operations more efficiently in a moment when every hour and dollar counts.
Hence not all code equal and the site standards and that history as well as knowing that can make an almighty difference.
Never had copybook issues with ICL or Honeywell BULL platforms ;). That would be an IBM thang, but then, is there anything else still running - probably.
I’m newer to the mainframe industry but not that new and I’ve never seen a place that doesn’t have a source control repository. In fact, it’s required by law in every company I’ve worked for.
What's obvious in 2020 was cutting-edge and forward-thinking in 1960. The rude kids of 2080 may sneer at your best code circa 2020.
The most shocking story was about their system for tracking Medicaid patients. Their system had a fixed-width field for the patient's ID, and they ran out of identifiers - so they just started to recycle them again from the beginning. This problem was multiplied by the fact that, to say money, they didn't have backups of the original, clean data before the recycling. Thus it became pretty much impossible to understand what benefits had been afforded (or not) to whom.
Governmental budgeting seems biased strongly in favor of labor expenses, especially those with seniority, to the detriment of the maintenance of capital assets. This is pretty much a recipe for technological debt.
I was at the top of my pay grade just under architect and only two years out of college making around 68k a year in Olympia. Olympia is not a cheap place to live. On top of that you’re basically legislates NOT to do work.
The prevalence of COBOL and other older programming languages in many parts of the world's critical infrastructure (unemployment claims here, finance, government, defense) means that the average age of someone maintaining these systems tends older. Older people tend to have more health issues. From the summaries of reports I read about COVID-19, the majority of the deaths happen among the elderly and those with other health conditions.
The idea of civilization collapsing might seem fanciful and farfetched, but the idea struck me after watching a video that was submitted here on HN and the videos it references [0][1][2][3].
[0] Jonathan Blow - Preventing the Collapse of Civilization (English only) - https://www.youtube.com/watch?v=pW-SOdj4Kkk
[1] Preventing the Collapse of Civilization [video] - https://news.ycombinator.com/item?id=19945452
[2] https://www.youtube.com/watch?v=OiNmTVThNEY - https://www.youtube.com/watch?v=OiNmTVThNEY
[3] Eric Cline | 1177 BC: The Year Civilization Collapsed - https://www.youtube.com/watch?v=hyry8mgXiTk
My point is that this absolutely is a funding and priority issue. I work as a developer who maintains legacy FORTRAN code. It was written in an era where global variables and Go To statements were the norm. Everyone who wrote it is retired or dead. It’s a pain to work with and there are parts that I haven’t yet gathered the courage to go in and change. However, me and my team have made substantive changes to it that are robust, that we have rigorously tested. This is not impossible, but it’s also not cheap or fast. It took me a year to understand how this blob of code works.
My team is young, we’re in our 20s, with backgrounds in CS, mechanical engineering, and physics. Certainly all systems are different, but if we can understand old FORTRAN, similar people can understand old COBOL. If people made it, people can understand it. We also know how to fix many broken things and how to fix many bugs. Often were told by management “not right now” and “we don’t have funding for that.” It’s frustrating, but that’s how the world works. They at least have funding to pay us to do what we’re doing now.
The point is that you can fix legacy systems, you can hire new people to do it, but it is expensive and it takes time. The whole issue is not whether we can or can’t, we can. The issue is: who can pay for it and will they?
The problem with code is that most non technical companies don’t have a clue how this thing works. They use analogies. And for most folks the analogy is that of a machine that once built never breaks down. If you can demonstrate viscerally how bad the system is, it can help get better support.
The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration.
> The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.
I've never made butter, but I have used raw milk. And I've failed at whipping cream, by overdoing it. So from what I've seen, "making butter" is basically just agitating cream until the fat clumps, and then pressing out the whey.
Making bread, I admit, takes more skill.
My mother knew how to make blood pudding. But that's not something I miss very much.
Puerto Rico was without electricity for months. Some parts of the West will recover from the economic effect of the pandemic quickly. Others won't, without help from the center.
I love how pop culture always portrays the collapse as coming from our inability to maintain or repair some mythical machine or technology. Never once did I imagine that it was the state welfare software.
In many cases, it's literally not legal for them to do so.
For example, at the Federal level: https://en.wikipedia.org/wiki/General_Schedule_(US_civil_ser...
(These restrictions don't tend to apply to hiring one via a contractor at $250-500k/year, though. Sigh.)
If you're making that kind of money, you have a lot better options than working on some ancient COBOL system that processes unemployment claims.
[1] https://info.csc.state.nj.us/Vats/WebAnno.aspx?FileNumber=30...
[2] https://info.csc.state.nj.us/Vats/WebAnno.aspx?FileNumber=30...
Maybe $0 is hyperbole, but there is no chance NJ makes good on all of its defined benefit pension promises, and I would rather just get all cash/401k as compensation.
https://www.truthinaccounting.org/news/detail/financial-stat...
Dead Comment
While there are problems with lowest-bidder-win, the real issue here is that systems like this are more living and breathing than one-off; you need a teams that tend to them, not bringing in a contractor.
Lack of foresight, lack of understanding that codebases are a living thing and are never "done". But hey, let's all work for ad companies and put our best minds at solving how we could make people see more ads!
Isn't it the power of the executive branch to requisition corporations or people in time of deep crisis in order maintain the continuity of government and its critical systems? Isn't unemployment claims such a critical system?
Deleted Comment
UI is mostly federally funded so they need to coordinate with them, and the complexity of the business rules and minimal funding during good times makes it a difficult task.
Also these systems generally work well, and it’s hard to fix things that aren’t broken. They just cannot handle the never before seen volume — it’s unlikely that a more modern enterprise system would either.
sorry but that is just false. a Properly designed modern system would handle horizontal scaling just fine.
Granted the government would likely pay a billion dollars to have a screwed up system developed by on of the "big guys" that has the same problems as they current system, most likely because it would be designed by committee and not by engineers.
However to say that modern systems could not handle this kind of problem is just wrong. There are all kinds of ways to handle a sudden increase in load.
And this is a department that have billions.