I often think that publicly funded software should be required to be open source (with some obvious exceptions). After all, if taxpayers paid for the software, shouldn't they be able to see the...
I often think that publicly funded software should be required to be open source (with some obvious exceptions). After all, if taxpayers paid for the software, shouldn't they be able to see the software?
Anecdotally, it seems that we often hear about nightmare software projects that are billions over budget or massively out of date and I always wonder how and why we got into this state. I feel like it's probably because of lack of knowledge about how software works in government, and companies wanting to make as much money as possible - an interesting confluence between the public and private sectors. I feel like open sourcing things might go some way to fixing this sort of interaction.
Emphatically agreed. Gov.uk is a brilliant example of how it can be done right - all of their code is published on github and the services that they run tend to just... work. It's a unified portal...
Exemplary
Emphatically agreed. Gov.uk is a brilliant example of how it can be done right - all of their code is published on github and the services that they run tend to just... work. It's a unified portal for all of the general admin and interaction that happens between citizens and government, and they've spent the better part of the last decade absorbing services one by one into the new system.
I've seen James Stewart, the guy behind the whole project, speak a couple of times and I enjoy how candid he was about saying, in essence, "this didn't actually need to be a difficult or expensive problem". Apparently one of the first and most influential things that needed to be done was just stick a big reminder on the window saying "your users are out there"; stop building to the letter of a spec, start building to the task that a person needs to achieve. Most interactions that most people have with the government really aren't that complicated - all they really need is a simple form or search page - so spending the money on good UI/UX and keeping everything consistent is all that's needed to make it pleasant to use.
The first iteration of gov.uk cost £1.7m, which is a drop in the bucket for a government project. To any small company or dev agency, £1.7m to build a nice accessible website with some forms and some sensibly organised documents is eye-popping luxury. So why the disconnect?
Part of it is bureaucracy: responding to a tender is an art in and of itself, not to mention being extremely time consuming with no guarantee of payoff. The scales are tilted in favour of the lumbering old guard, who often deliver an outdated design-by-committee product at a hugely inflated price.
Part of it is good old fashioned cronyism and corruption: tenders are written in such a specific way that only one company could possibly fulfil them, and that company happens to be some minister's sister in law's major investment. I want to believe that this is mostly being stamped out by appropriate oversight, but I also think that's probably an optimistic view.
Part of it, and in my opinion the largest part, is that highly technical projects are exceptionally difficult to judge by laypeople: if the experts nod sagely and say it'll take five years and a fully funded team, then that's what gets paid for. The problem is that thanks to points one and two, those trusted experts tend to be drawn from the same small array of huge companies that are bidding for the tenders. Add a bit of buzzword-compliant technobabble, claim you're the only firm with the capability to fulfil it, and add a zero to the price. In the worst case, you end up with Lyle Lanley making a particularly compelling bid to sell you something that's not just useless but actively dangerous.
If gov.uk is an example of how things should be done, then the NHS presents the opposite. Billions upon billions have been thrown into a black hole, and the software just doesn't fucking function. Doctors' lives are made incrementally harder each and every day for no good reason. To this day, it makes me deeply, viscerally angry. The enormous waste of money that should be keeping people alive is bad enough, but to have that kind of overspend and still not have a working system is unforgivable.
It's record keeping. We've been working on software that does this, and does this well, since the 80s. Think of the team you could assemble, the software you could write, the hardware you could distribute for an eleven digit budget.
And yeah, if that software had been developed openly and published incrementally on a public platform, interested parties (i.e. the people whose lives may depend on it) can provide oversight of their own. We can shine a light on the difficult (or lack thereof) of the task. Other governments, other healthcare systems, other humans can benefit from money that was being spent anyway.
I'll end on a positive. The alphagov software, the core of gov.uk, is being used by local and regional governments around the world. Where national governments have the money to spend, local governments don't. And so, unexpectedly, an exercise in transparency and user-focused design has helped grassroots community services globally.
I saw a discussion about this on HN last week and everyone kept say that it was more practical to teach people these mostly obsolete programming language than it is to just rebuild everything in a...
I saw a discussion about this on HN last week and everyone kept say that it was more practical to teach people these mostly obsolete programming language than it is to just rebuild everything in a modern language. But I have to wonder how true that really is? Seems like every time there's a surge in use of these old systems down the pipeline (tax refunds, healthcare.gov, unemployment, etc.) they completely buckle under the pressure and cause delays.
I won't pretend to have experience with things so massive and critical, but like...why aren't there plans in the works to throw a bunch of teams and modernizing these systems? Especially now, while there are still some industry veterans available to help port code!
Rewrites of large systems are expensive and high-risk. Many experienced programmers recommend against them. Often they fail. There are other strategies, like rewriting parts of the system, but you...
Rewrites of large systems are expensive and high-risk. Many experienced programmers recommend against them. Often they fail.
There are other strategies, like rewriting parts of the system, but you still need to be concerned about the interface between the new stuff and the old stuff.
They don't buckle under the pressure because the languages are old, they buckle under the pressure because they've been hastily patched, maintained, and updated by dozens of different contractor...
Seems like every time there's a surge in use of these old systems down the pipeline (tax refunds, healthcare.gov, unemployment, etc.) they completely buckle under the pressure and cause delays.
They don't buckle under the pressure because the languages are old, they buckle under the pressure because they've been hastily patched, maintained, and updated by dozens of different contractor teams over 40 years under basically non-existent standards for documentation and version control. Contractor changeovers also tend to be a bit hostile, so everyone involved has an incentive to make sure whoever they lost the contract to does a bad job and can't benefit from anything they learned. The code is bound to be abominable under those conditions. Even people who know COBOL like the backs of their hands wouldn't want to work on something like that, and it's totally unrelated to the language itself. It's needing to untangle 40 years of code rot.
The only reason this stuff still, more or less, still works is because they're written in these very basic languages. If they were written in something "modern" you'd get 5 years before catastrophic failure. (And, knowing what I know about the government, if they overhauled these today it would be just a giant mess of Javascript.)
FWIW, if you are willing to try and slay this dragon you can get trained in COBOL for free.. From what I've heard it's not terribly hard to learn, though I haven't bothered trying.
I think healthcare.gov is a different story. That was a new system being built, and it still was awful! Far easier to make new systems than modernize old ones. If you want a rewrite &...
I think healthcare.gov is a different story. That was a new system being built, and it still was awful! Far easier to make new systems than modernize old ones. If you want a rewrite & modernization it'll just be the US throwing these systems to the same crappy contractors that screwed up healthcare.gov...
Of course, the requirements for a lot of these systems (and current functionality) are likely unknown, so that makes it even worse.
The US government just needs better engineers, and they probably need to keep them on staff.
To be fair, the only "new" part of the system was the website front end. Everything else was needing to interact with old AF databases from CMS and Social Security and on and on. The US government...
Far easier to make new systems than modernize old ones.
To be fair, the only "new" part of the system was the website front end. Everything else was needing to interact with old AF databases from CMS and Social Security and on and on.
The US government just needs better engineers, and they probably need to keep them on staff.
The US government needs better everything. Their hiring processes are byzantine and reward familiarity with government processes over objective competencies at anything else. It's all designed for olden days when the primary tasks of government were all clerical and administrative. It's tragically out of step from today, where the lion's share of it is knowledge work.
The reason I mention healthcare.gov is that I seem to recall some of the early problems being that it depended on social security infrastructure for some piece of it (probably identity...
The reason I mention healthcare.gov is that I seem to recall some of the early problems being that it depended on social security infrastructure for some piece of it (probably identity verification). And that ended up being a point of failure. But I could be misremembering.
Often there are or have been plans in the work and they turned out to be more expensive or take more time than was initially budgeted for. Rebuilding complext old systems like that to newer ones...
Often there are or have been plans in the work and they turned out to be more expensive or take more time than was initially budgeted for. Rebuilding complext old systems like that to newer ones is a huge undertaking as they contain a lot of internal logic that needs to work the same in the newer systems. The problem is often that there is nobody around anymore who understands all the logic in there making it a tedious puzzle game to just figure out what does what and how it ties together.
And you can't really afford to make mistakes here either as that means that people might not got their unemployment checks if the system goes live.
This pretty much sums up this whole fiasco. I do not think COBOL as a language is bad or good. It is a programming language which was the lingua franca of the times a lot of these systems were...
“Whenever there was a problem with the IT, COBOL is the scapegoat,” Hinshaw said. “IT systems always get the short-end of the stick when it comes to funding.”
This pretty much sums up this whole fiasco. I do not think COBOL as a language is bad or good. It is a programming language which was the lingua franca of the times a lot of these systems were built.
The problem is, the people responsible for these systems have not done their jobs for several decades in keeping up with the times and have accrued massive technical debt.
Now, that there is a crisis, these systems are breaking under a massive load and they throw IT/COBOL under the bus.
There was interesting discussion on another post in HackerNews here on an article announcing IBM is providing free COBOL training. I do not think that learning COBOL is going to be hard for most backend developers. The problem is going to be able to understand these archaic systems, which were written in a time where good coding practices were non-existant (no comments, bad variable names, etc). Being able to make worthwhile changes to these system is not going to be easy.
Another interesting comment on the HN post was also:
The IRS, treasury, and others locally are looking for COBOL programmers. I can explain why they're struggling to find any just by looking at the pay scale: $30,113 - $86,021 (GS-5 through GS-12, and most won't get the top end of the GS-12 scale). The $30K GS-5 starting is almost as low as working for their call center which is farcical.
By contrast state, county, and even city government are paying $65K - $85K starting going all the way up to $100K at the top end. And these are jobs where you're doing modern development, not COBOL.
People will start learning COBOL as soon as it makes rational sense. As it stands a lot of organizations aren't looking for any COBOL developer, they're looking for CHEAP COBOL developers. It doesn't make sense to learn when you'd lose money for taking those jobs.
It’s just an older language that is probably not so useful for modern projects. So you’d be learning it to either learn computer history, learn some specific aspects of programming that this...
It’s just an older language that is probably not so useful for modern projects. So you’d be learning it to either learn computer history, learn some specific aspects of programming that this language is good for, or to maintain historical systems. All worthwhile things but for a new programmer trying to make income it might not be the most efficient use of their time. Idk, I don’t know COBOL!
Like a lot of older languages, COBOL is... tedious to code, to say the least. Most people today learn coding with a modern language like Python, Java, Rust, JS, C#, etc. Going from those languages...
Like a lot of older languages, COBOL is... tedious to code, to say the least. Most people today learn coding with a modern language like Python, Java, Rust, JS, C#, etc. Going from those languages to COBOL is a slap in the face and to most people it just isn't worth the money, even though there is a lot of money to be made.
Not to be ageist or anything, but there's a particular team culture that evolves when everyone involved is a very old White guy who is past retirement and only in it for the money with no concern...
Going from those languages to COBOL is a slap in the face and to most people it just isn't worth the money, even though there is a lot of money to be made.
Not to be ageist or anything, but there's a particular team culture that evolves when everyone involved is a very old White guy who is past retirement and only in it for the money with no concern for making friends, learning new things, handling interesting challenges, being a team player, etc.
It's not a pleasant work environment, even when the task is pleasant.
On top of what others have rightly said about relevance/ease of use, the only actual jobs in COBOL are going to be working with 40+ year old legacy code that's been patched and partially rewritten...
On top of what others have rightly said about relevance/ease of use, the only actual jobs in COBOL are going to be working with 40+ year old legacy code that's been patched and partially rewritten by a stream of developers who have long since moved on.
Even in, say, Java, maintaining legacy code is often painful. Maintaining really old, sprawling, complex code with minimal documentation, half of which is outdated enough to be actively wrong or misleading, is an absolute slog. You're spending your days tracing confusingly named variables between sections written by different people, figuring out why there are seven subtly different implementations of the same function across the codebase, discovering that two conflicting source repositories exist and nobody is certain which is the approved one or why they differ, and any number of other similar things.
If you learn COBOL, you're accepting that all the jobs you take will be like that. The fact that the language is also making life more difficult for you would almost be an afterthought for me.
But yeah, they money's great and someone has to do it - if you've got the mindset and the patience for that kind of work then absolutely go for it!
COBOL is so ancient you literally learn 0 skills applicable to the rest of the world. However, so long as ancient mainframes are kept around you can make decent money.
COBOL is so ancient you literally learn 0 skills applicable to the rest of the world. However, so long as ancient mainframes are kept around you can make decent money.
A most have already pointed out COBOL is ancient. However, I think the issue with the government agencies not being able to find COBOL developers is more due to how much they are willing to pay...
A most have already pointed out COBOL is ancient. However, I think the issue with the government agencies not being able to find COBOL developers is more due to how much they are willing to pay for these developers.1
As soon as it will make economic sense for more people to learn COBOL, they will. As of now, there is more demand for jobs in other languages where a developer will be able to earn more and not have to work in an archaic language.
There are jobs in other industries (like finance) where they still use COBOL, however the number of positions for these isn't huge. There is also not a lot of turnover in a lot of those positions...
There are jobs in other industries (like finance) where they still use COBOL, however the number of positions for these isn't huge. There is also not a lot of turnover in a lot of those positions (anecdotal, I could be wrong). A lot of these systems have also steadily been migrating away from COBOL.
So the supply-demand for COBOL developers, kinda normalizes how many people actually get into COBOL and stick with it.
And it certainly doesn't help that a lot of "retired" programmers also tend to temporarily come out of retirement to snag those high paying jobs, too. My best friend's Dad is a COBOL/FORTRAN...
however the number of positions for these isn't huge.
And it certainly doesn't help that a lot of "retired" programmers also tend to temporarily come out of retirement to snag those high paying jobs, too. My best friend's Dad is a COBOL/FORTRAN programmer and even at 70+ years old still occasionally goes back to working whenever a good enough paying opportunity presents itself. E.g. During Y2K he consulted for several Canadian banks to help them update their legacy systems' code, and he made insane money doing so.
I often think that publicly funded software should be required to be open source (with some obvious exceptions). After all, if taxpayers paid for the software, shouldn't they be able to see the software?
Anecdotally, it seems that we often hear about nightmare software projects that are billions over budget or massively out of date and I always wonder how and why we got into this state. I feel like it's probably because of lack of knowledge about how software works in government, and companies wanting to make as much money as possible - an interesting confluence between the public and private sectors. I feel like open sourcing things might go some way to fixing this sort of interaction.
Emphatically agreed. Gov.uk is a brilliant example of how it can be done right - all of their code is published on github and the services that they run tend to just... work. It's a unified portal for all of the general admin and interaction that happens between citizens and government, and they've spent the better part of the last decade absorbing services one by one into the new system.
I've seen James Stewart, the guy behind the whole project, speak a couple of times and I enjoy how candid he was about saying, in essence, "this didn't actually need to be a difficult or expensive problem". Apparently one of the first and most influential things that needed to be done was just stick a big reminder on the window saying "your users are out there"; stop building to the letter of a spec, start building to the task that a person needs to achieve. Most interactions that most people have with the government really aren't that complicated - all they really need is a simple form or search page - so spending the money on good UI/UX and keeping everything consistent is all that's needed to make it pleasant to use.
The first iteration of gov.uk cost £1.7m, which is a drop in the bucket for a government project. To any small company or dev agency, £1.7m to build a nice accessible website with some forms and some sensibly organised documents is eye-popping luxury. So why the disconnect?
Part of it is bureaucracy: responding to a tender is an art in and of itself, not to mention being extremely time consuming with no guarantee of payoff. The scales are tilted in favour of the lumbering old guard, who often deliver an outdated design-by-committee product at a hugely inflated price.
Part of it is good old fashioned cronyism and corruption: tenders are written in such a specific way that only one company could possibly fulfil them, and that company happens to be some minister's sister in law's major investment. I want to believe that this is mostly being stamped out by appropriate oversight, but I also think that's probably an optimistic view.
Part of it, and in my opinion the largest part, is that highly technical projects are exceptionally difficult to judge by laypeople: if the experts nod sagely and say it'll take five years and a fully funded team, then that's what gets paid for. The problem is that thanks to points one and two, those trusted experts tend to be drawn from the same small array of huge companies that are bidding for the tenders. Add a bit of buzzword-compliant technobabble, claim you're the only firm with the capability to fulfil it, and add a zero to the price. In the worst case, you end up with Lyle Lanley making a particularly compelling bid to sell you something that's not just useless but actively dangerous.
If gov.uk is an example of how things should be done, then the NHS presents the opposite. Billions upon billions have been thrown into a black hole, and the software just doesn't fucking function. Doctors' lives are made incrementally harder each and every day for no good reason. To this day, it makes me deeply, viscerally angry. The enormous waste of money that should be keeping people alive is bad enough, but to have that kind of overspend and still not have a working system is unforgivable.
It's record keeping. We've been working on software that does this, and does this well, since the 80s. Think of the team you could assemble, the software you could write, the hardware you could distribute for an eleven digit budget.
And yeah, if that software had been developed openly and published incrementally on a public platform, interested parties (i.e. the people whose lives may depend on it) can provide oversight of their own. We can shine a light on the difficult (or lack thereof) of the task. Other governments, other healthcare systems, other humans can benefit from money that was being spent anyway.
I'll end on a positive. The alphagov software, the core of gov.uk, is being used by local and regional governments around the world. Where national governments have the money to spend, local governments don't. And so, unexpectedly, an exercise in transparency and user-focused design has helped grassroots community services globally.
I saw a discussion about this on HN last week and everyone kept say that it was more practical to teach people these mostly obsolete programming language than it is to just rebuild everything in a modern language. But I have to wonder how true that really is? Seems like every time there's a surge in use of these old systems down the pipeline (tax refunds, healthcare.gov, unemployment, etc.) they completely buckle under the pressure and cause delays.
I won't pretend to have experience with things so massive and critical, but like...why aren't there plans in the works to throw a bunch of teams and modernizing these systems? Especially now, while there are still some industry veterans available to help port code!
Rewrites of large systems are expensive and high-risk. Many experienced programmers recommend against them. Often they fail.
There are other strategies, like rewriting parts of the system, but you still need to be concerned about the interface between the new stuff and the old stuff.
They don't buckle under the pressure because the languages are old, they buckle under the pressure because they've been hastily patched, maintained, and updated by dozens of different contractor teams over 40 years under basically non-existent standards for documentation and version control. Contractor changeovers also tend to be a bit hostile, so everyone involved has an incentive to make sure whoever they lost the contract to does a bad job and can't benefit from anything they learned. The code is bound to be abominable under those conditions. Even people who know COBOL like the backs of their hands wouldn't want to work on something like that, and it's totally unrelated to the language itself. It's needing to untangle 40 years of code rot.
The only reason this stuff still, more or less, still works is because they're written in these very basic languages. If they were written in something "modern" you'd get 5 years before catastrophic failure. (And, knowing what I know about the government, if they overhauled these today it would be just a giant mess of Javascript.)
FWIW, if you are willing to try and slay this dragon you can get trained in COBOL for free.. From what I've heard it's not terribly hard to learn, though I haven't bothered trying.
Once you've learned COBOL the real beast to slay is the 40 year old legacy code base written by 50 different contractors of varying skill levels.
I think healthcare.gov is a different story. That was a new system being built, and it still was awful! Far easier to make new systems than modernize old ones. If you want a rewrite & modernization it'll just be the US throwing these systems to the same crappy contractors that screwed up healthcare.gov...
Of course, the requirements for a lot of these systems (and current functionality) are likely unknown, so that makes it even worse.
The US government just needs better engineers, and they probably need to keep them on staff.
To be fair, the only "new" part of the system was the website front end. Everything else was needing to interact with old AF databases from CMS and Social Security and on and on.
The US government needs better everything. Their hiring processes are byzantine and reward familiarity with government processes over objective competencies at anything else. It's all designed for olden days when the primary tasks of government were all clerical and administrative. It's tragically out of step from today, where the lion's share of it is knowledge work.
The reason I mention healthcare.gov is that I seem to recall some of the early problems being that it depended on social security infrastructure for some piece of it (probably identity verification). And that ended up being a point of failure. But I could be misremembering.
Often there are or have been plans in the work and they turned out to be more expensive or take more time than was initially budgeted for. Rebuilding complext old systems like that to newer ones is a huge undertaking as they contain a lot of internal logic that needs to work the same in the newer systems. The problem is often that there is nobody around anymore who understands all the logic in there making it a tedious puzzle game to just figure out what does what and how it ties together.
And you can't really afford to make mistakes here either as that means that people might not got their unemployment checks if the system goes live.
This pretty much sums up this whole fiasco. I do not think COBOL as a language is bad or good. It is a programming language which was the lingua franca of the times a lot of these systems were built.
The problem is, the people responsible for these systems have not done their jobs for several decades in keeping up with the times and have accrued massive technical debt.
Now, that there is a crisis, these systems are breaking under a massive load and they throw IT/COBOL under the bus.
There was interesting discussion on another post in HackerNews here on an article announcing IBM is providing free COBOL training. I do not think that learning COBOL is going to be hard for most backend developers. The problem is going to be able to understand these archaic systems, which were written in a time where good coding practices were non-existant (no comments, bad variable names, etc). Being able to make worthwhile changes to these system is not going to be easy.
Another interesting comment on the HN post was also:
It’s just an older language that is probably not so useful for modern projects. So you’d be learning it to either learn computer history, learn some specific aspects of programming that this language is good for, or to maintain historical systems. All worthwhile things but for a new programmer trying to make income it might not be the most efficient use of their time. Idk, I don’t know COBOL!
Like a lot of older languages, COBOL is... tedious to code, to say the least. Most people today learn coding with a modern language like Python, Java, Rust, JS, C#, etc. Going from those languages to COBOL is a slap in the face and to most people it just isn't worth the money, even though there is a lot of money to be made.
Not to be ageist or anything, but there's a particular team culture that evolves when everyone involved is a very old White guy who is past retirement and only in it for the money with no concern for making friends, learning new things, handling interesting challenges, being a team player, etc.
It's not a pleasant work environment, even when the task is pleasant.
On top of what others have rightly said about relevance/ease of use, the only actual jobs in COBOL are going to be working with 40+ year old legacy code that's been patched and partially rewritten by a stream of developers who have long since moved on.
Even in, say, Java, maintaining legacy code is often painful. Maintaining really old, sprawling, complex code with minimal documentation, half of which is outdated enough to be actively wrong or misleading, is an absolute slog. You're spending your days tracing confusingly named variables between sections written by different people, figuring out why there are seven subtly different implementations of the same function across the codebase, discovering that two conflicting source repositories exist and nobody is certain which is the approved one or why they differ, and any number of other similar things.
If you learn COBOL, you're accepting that all the jobs you take will be like that. The fact that the language is also making life more difficult for you would almost be an afterthought for me.
But yeah, they money's great and someone has to do it - if you've got the mindset and the patience for that kind of work then absolutely go for it!
COBOL is so ancient you literally learn 0 skills applicable to the rest of the world. However, so long as ancient mainframes are kept around you can make decent money.
A most have already pointed out COBOL is ancient. However, I think the issue with the government agencies not being able to find COBOL developers is more due to how much they are willing to pay for these developers.1
As soon as it will make economic sense for more people to learn COBOL, they will. As of now, there is more demand for jobs in other languages where a developer will be able to earn more and not have to work in an archaic language.
There are jobs in other industries (like finance) where they still use COBOL, however the number of positions for these isn't huge. There is also not a lot of turnover in a lot of those positions (anecdotal, I could be wrong). A lot of these systems have also steadily been migrating away from COBOL.
So the supply-demand for COBOL developers, kinda normalizes how many people actually get into COBOL and stick with it.
And it certainly doesn't help that a lot of "retired" programmers also tend to temporarily come out of retirement to snag those high paying jobs, too. My best friend's Dad is a COBOL/FORTRAN programmer and even at 70+ years old still occasionally goes back to working whenever a good enough paying opportunity presents itself. E.g. During Y2K he consulted for several Canadian banks to help them update their legacy systems' code, and he made insane money doing so.