Why the UK public sector still creaks along on COBOL The UK government has gone all-in on AI. More than 50 years after Harold Wilson gave his famous "White heat of technology" speech, this is the hot new thing. An AI Strategy has been released. Datacenters are planned. Steps to strengthen AI supply chains are being formulated. And of course, the public sector will lead by example …
Indeed: rebrand those old systems as COBoL Ai Systems, or COBLAS - then we can get on with maintaining a bunch of old COBLAS.
I know, I know, deeply unfair to COBOL. I used to code a bit of COBOL back in the 80s for BT. Ugly and tedious, but rock-solid and highly maintainable. More than a few of my colleagues at the time decamped to places like the UAE where they could earn top, errm, dirham as COBOL coders. My suspicion would be that many of those "legacy" systems the article talks about ain't that broke and don't actually need so much fixing.
The easy solution is to train more Cobol programmers.
As has been said, Cobol is ugly and clunky, but it does what it does very well. It was designed specifically for commercial tasks, unlike many of its successors which may be more elegant mathematically, but are pants at handling business tasks.
I speak as one who has suffered the ravages of Cobol, but even more from trying to code business tasks (invoicing, stock control, ...) in C(++) or Java.
Last year I dug out some old university COBOL stuff from the 1980s, downloaded a modern COBOL compiler, and had a play around with it. I think I have enough flexibility to retrain as entry-level COBOL engineer, and can bluff the essential "must have 30 years' experience" that entry-level jobs demand as well.
Comments!? I've never yet seen any.
For context, in the 70s and 80s I spent about 10 years [automatically] converting Cobol programs between dialects [1]. In the millions of lines that we processed only one program had any comments, and the customer complained that we rotted up the formatting.
[1] In theory there are some 186000 *standard conforming* Cobol dialects, not counting implementor defined features.
They're really not that broke. If at all.
The problem seems to be that the knowledge of the systems and the skills required to keep them maintained are hard to come by, which will be a continual problem as programmers and techs move on, retire etc.
In 40 years we will probably be desperate for legacy C prgrammers
> The problem seems to be that the knowledge of the systems and the skills required to keep them maintained are hard to come by
Agreed. Problem is, this has been the issue for some time (many decades).
A while ago I considered getting off the bleeding edge and supporting legacy systems instead. Problem was, I looked at a few, and while the original coders were clearly excellent (better than me), the systems had been mutilated by increasing levels of idiots over the years, and some were incomprehensible. Got to admit, I thought **** this and went back to the new stuff.
Can someone remind me ... Is it replace old systems with known bugs - with new systems with unknown bugs. Move fast and break things?
People often forget that the test suite is often larger than the "product" it tests. It has to do all the edge cases, performance, scalability, security, security validations (no you cannot have access) reporting, encryption of fields etc. The functions that "no one uses". A bank turned off a server which was "never used". It was used once a year at audit time for about 4 days.
If you go from screen scraping enter customer number in the first field of the old system, to its now the third field in the new system, this soon becomes a problem.
Dividing a system so you can isolate components, and have clean interfaces between components can make some of these transformations easier. Start by converting green screens to http and web pages ,so you can have named fields. This makes automation much easier.
Someone said that some of these projects are like trying to replace the engine of a jet - whilst in flight.
I don't get it: insurance companies, banks etc still have main frame systems, often with COBOL code (or assembler code). The legacy systems are all mission critical, centre of business. Migration thus is extremely difficult, expensive and high risk as well as low return. I was told by my brother who does IT projects that he had a few where companies would approach them, they would do the analysis, and then they'd just get another rack from IBM and be done with it - due to cost, risk, duration of the migration. I like the picture of replacing a jet engine mid flight.
One of my friends works in a government (not the UK) project where they are trying to migrate away from their current mainframe system and lift all IT into the modern times, rather than being stuck in the IT-equivalent of the paleozooikum. The problem is of course that the current system still needs to run, support new legislation, new client systems, and the new systems do not support the currently needed data throughput (at the moment). It is decades of work with the manpower they have.
ISTR that the Charon VAX emulators ran considerably faster than the systems they were replacing. (Which is fine and dandy for pure software processing grunt - but does not necessarily help you if you are interfacing with legacy hardware or have 'special' system architecture requirements [e.g. redundancy/fail-op fail-safe].
Still, a useful solution where you have a great deal of 'value' embodied in your legacy software systems.
This is the usual argument. It's working fine, we only need one person to patch it for new tax rules and things like that, come on, the new system would do the same things the old system does, right up until something massive breaks. Maybe hardware breaks and oh no, this was designed in a way that doesn't work on anything new. Maybe your one programmer becomes unavailable and someone you hire quickly to get ready for new regulations takes a look at the code and announces that this is not going to be ready by the time the regulations need it to be. Maybe someone accesses the system which was designed for the kind of security issues faced in the 1980s but connected to systems that face attacks in the 2020s and encrypts and/or copies it. Maybe that one programmer reads a regulation wrong and, since you didn't have more, nobody catches it because there's no code review. Nobody wants to do the work, which is why they generally don't until the problems are big enough to be their problem rather than the individuals whose data is being processed.
Nobody wants to rebuild it. The people paying for it don't want it, but neither do the programmers. The ones on the old system don't want to start from scratch. New ones don't want to be blamed when the version they're building from the best understanding of what the old one does ends up making a mistake the old one wouldn't. That doesn't mean it's not worth doing.
I trained as a COBOL dev back in the 80's, so all I can say is: "Yay, COBOL!!!"
The fact that we are no longer training people to maintain 'legacy code' is very often THE PROBLEM, rather than the code itself.
OTOH, I am sure there are cases where $CODING_LANG [name] was all they had to work with, despite the massive security holes, etc. so a re-write in something a little safer would be well worth the expense.
My great-grandfather's set square is certainly old, but it still nails a right-angle every time.
Not training people to maintain it is only half the problem. The other half is the ongoing political creation of ever more complex piles of requirements as politicians thrash around trying to make reality fit their ideas. Thatt's what introduces the need for "maintenance" in the first place.
Bu those legacy systems also contain undocumented workflows and business logic due to (in the words of the article) 'encode[d] arcane policy'. You could be a COBOL grandmaster, and still not be able to figure out what the f**k the program is doing. Anyone who has ever been told to debug someone else's 10,000-line program will know what I'm talking about.
I'd even think you could get some kind of domain-specific LLM to do the analysis for you, as is happening in material sceince and chemistry. Maybe even generate a state machine to do this. But that would be boring and too simple for the contractors beating doors down to sell inappropriate tools for the job.
What would be the output of that analysis, i.e. what do you expect the state machine or LLM to deliver to help with the system migration?
You can probably automatically translate Cobol to some other programming language like C(++) or Java or Rust but you'll end up with code that is harder to understand than the original Cobol and thus will be even harder to maintain or adapt to new requirements.
At least COBOL was intended to be read, unlike C and its successors like Rust…
As for “ undocumented workflows and business logic”, that is the norm for anything developed through Agile, Scrum, Hackathon et al.
I remember developing a field engineer work scheduling system where engineers could work from home, it was going so well until someone remembered health and safety and that the morning trip into the office (sign in) and the end of shift return to office (sign out) acted as a check that the engineer was alive and well and so didn’t need a search party …
I swear to god all the absolute worse programming f**kups I have ever had to deal with were caused by ‘clever’ programming in ‘concise’ languages.
The human brain requires large amounts of redundancy in written language to aid rapid and reliable understanding of meaning. It’s something common to all modern written languages in one form or another.
Many programming languages go directly against that, as if compressing the maximum amount of complexity into the lowest character count is somehow desirable. And they unironically call it expressiveness, and mock languages like Ada and COBOL as verbose because they require much greater redundancy and specific declaration of intent.
This is largely why the current cybersecurity clusterfuck is destroying the house of cards we have built on programming languages like C.
In a way, but we already have that in the form of writing good comments. Knuth's approach was more blatant about it, but it has the same problem that any comments do, specifically that nothing requires them to exist or verifies that they're correct. That means it's easy to skip them for any of the reasons that people often do, and more dangerously it's easy not to update them when the code gets updated.
I don't know if I can agree with the original post. I've seen plenty of code written by people who adopted the poet's credo--if it's difficult to understand, that means you're smarter than the reader--but I don't think the language made much of a difference. For example, one of the easiest ways to make code opaque is to use bad names. No language polices the quality of names. No language feasibly could anyway. You can easily write code that's hard to read without intending to just by thinking that what was obvious to you will be obvious to someone else and being wrong.
I agree with all of that, OTOH at a basic 'human' level good structure and a syntax that serves the meat-sack in the chair (as well was the compiler!), plus effective commenting all contribute to creating something that will stand the test of time, including a maintainer's hatchet/scalpel.
As you say, it's very easy to write obfuscated code, even without intending to: my genius/laziness is someone else's nightmare.
The problem isn't knowing what a line does. I think most people with a few years of experience can approach any language, and before the obvious corner cases crop up let's define "language" as a programming language used by multiple groups to write production software they rely on for financial benefit, and figure out what any given expression does with little more than a syntax introduction. I don't think Cobol's use of English words instead of punctuation helps in the slightest, because just like the punctuation in any other language, the words still have lots of effects on what the compiler produces that are not obvious from their dictionary definitions.
The problem is understanding what a lot of lines do together and whether they should be doing that. It's very easy for me to read a line of a language I've never seen and say "I understand this line is calling a function called ParseFile with a path and returning either the parsed result or an error code", but that doesn't tell me what kind of file this is, what uses this function path to parse things, what it's supposed to contain, what parsing consists of, what we are going to do with the output, what we can do but aren't doing with the output, or what the error codes are and mean. Nothing about Cobol helps to answer a single one of those questions. That's the needed information when doing anything useful with this code, whether that's adding new functionality in Cobol or rewriting it accurately in anything else. In some respects, Cobol may be a minor disadvantage because its wordiness and relative less structure when compared to other languages makes the process of manually parsing slower, but I don't think that's the biggest obstacle.
Well said! Its worth remembering that well-designed and carefully written COBOL was also pretty good at implementing technically oriented tasks too, as well as accounting and and payroll systems.
The most obvious example is IDMS, one of the earliest portable database implementations, which was written entirely in COBOL. The IDMS database drivers, maintenance and and support tools were all written in COBOL and, as IDMSX, a slightly enhanced version, it was the standard ICL-supported database for 2900 series mainframes.
AFAIK IDMS was never available on the 2903 and 2904 ranges, which ran standard 1900 code under a George 2 emulator on 2900 disk drive hardware.
I take particular exception to the use of charged words like "creaks". COBOL is designed to automate batch oriented business processes, something it does very well. A lot -- most, I'd guess -- modern code is focused on transaction processing, interactions between users and databases in (quasi) real time. AI might be useful for vibe coding database queries and the like but because something's popular doesn't mean its the only thing out there.
As an embedded systems programmer I work primarily in C but I also use several other languages. All programming languages have properties which make them particularly suitable for some types of tasks. I find that people who constantly push languages (and language versions) are usually unable to appreciate the underlying tasks that we're trying to perform, they're so obsessed with the 'how' that they don't consider the 'what', and worse still, they really expect their chosen language to solve their problems for them. (We had a tool for them once -- Visual Basic!)
"My great-grandfather's set square is certainly old, but it still nails a right-angle every time."
I have a flat bladed screwdriver that belonged to one of my G^2 fathers. He may have inherited it. It is capable of delivering a massive amount of torque and the properties of the steel at tip and on the shaft may well violate everything I learned about metallurgy!
I can put a stilson on the handle and tap with a rubber mallet and old school screws generally oblige me. A quick squirt of WD40 often helps too. You have to push down on the screw hard enough to remain engaged but not so hard that you lock the (rusted) thread even worse. The tapping needs to deliver enough torque but without snapping off the end of the blade. Obviously you have to consider that the screw might be rusted right through and will leave some behind. The tip is work hardened to just the right point and the shaft is mild enough to absorb shock.
Now that's a skill you don't see taught in school. If it all goes wrong, get the angle grinder and the other modern stuff out 8)
Government IT has special problems. It has a change of policy with every change of government - say every decade at the most and possibly more often than that- and a change of strategy with every change of minister - say every couple of years or more often than that. It also has to work all the time doing stuff that's been done for decades.
In an ideal world the keeping on doing stuff really shouldn't need maintenance at all. In the real world it's the changes of policy and strategy and general tinkering by everyone down to junior ministers that introduces the need for "maintenance"
The systems written in COBOL that are still running are still running because they're still running. They were rigorously designed and implemented and are still doing the job for which they were designed. If there are too few people who know COBOL these days then it's a simple matter of training people to use a clear, consistent and robust language.
... it's a simple matter of training people ...
Applying someone else's maxim - in theory there is no difference between the theory and practice of writing COBOL; in practice, there is. Some things are not as simple as one might hope. If you are really lucky the original implementer will have put a comment in explaining why something was done a particular way. Sadly it is often the case that things were considered "obvious" because it was common knowledge at the time (and these might be system specific).
I'm appalled at the Governments championing of AI and trying to fit it into every service as a solution (the Microsoft approach?). The technology just doesn't seem stable or ready for production use as a general tool. Yes, there has been achievements where its been used for a very specific use with a limited scope, but not as a general purpose tool. See https://www.quantamagazine.org/the-ai-was-fed-sloppy-code-it-turned-into-something-evil-20250813/
Even if it did work, AI would struggle to fix the issues caused by disjointed IT systems used by Government departments and quangos that were implemented as point solutions to requirements that have subsequently changed.
To be fair many of these problems also plague large firms that outsourced and have dug themselves into the same problems of a mix of ancient and new systems, multiple similar platforms from mergers and acquisitions, constant change in direction at the top, internal teams all out-sourced so zero internal skill or understanding left... IT is seen as a cost and to be reduced, whereas CEOs are lauded as geniuses and must be paid even more...
I've been on an internal IT teams, "outsourced" and now work for a small outsourcer. I'm often amazed by how much money large firms will pay for chocolate teapots from a big outsourcers... yet ignore their own staff or a smaller boutique firm that will give them a proper solution for a fraction of the price that will just work...
"Keeping legacy systems operational costs three or four times as much as maintaining modern systems. Yet the government is spending 30 percent less than its peers on IT overall, per the State of Government analysis."
So the UK government's IT spending is actually remarkably efficient when you compare it to peers??
"Legacy has a specific meaning in government, per the study: "unsupported, has known vulnerabilities, is difficult to maintain, or is unable to meet current business or user needs.""
Meaning all central government systems are legacy. There's not one that is not one of the above.
Actually I believe all government IT projects are required to not only massively over run and go way over budget, they are also required to deliver a legacy system that is unable to meet current business or user needs.
> > Why aren't we upgrading these systems more quickly?
The ever increasing maintenance overhead was known about prior to 1980, I remember it being covered at university - an IBM research paper? Possibly related to Fred Brooke’s Mythical Man Month…
Reducing maintenance costs was the prime motivation for the ITIL introduced by CCTA in the 1980s.
Because government is a departmental turf war and everything is run by people who neither know nor care about tech. Glorious Leader wants shiny AI datacentres and has been assured by his 100% honest tech bros that AI is a magic solution that will make Britain top nation again. And as they cannot import talent without Reform eating even more of their votes, they will have to retrain civil servants to be infosec specialists. Hey, it's only a small step from a 2.1 in art history to going head to head with malware gangs.
Reality: The same crappy outsourcers will be given a tonne of money to fail slowly again, whilst keeping the old stuff working.
COBOL systems will be replaced by Microsoft COBOL with AI.
The system-wide AI will be useless and cause endless disasters, some amusing, some leading to people dying.
Labour will lose by a landslide, Reform will get in and everything will just get even worse.
That's a fair point. 25% off sterling made a lot of other places more desirable than the economy that required easy access to migrant labour to function with any degree of productivity. About 10% of the UK are on NHS waiting lists (including me, for surgery), so the need is higher than ever just as the bans, blocks, fees and reduced desirability have driven people elsewhere. No matter how many policies the government launch, most of them stand no chance due to a lack of trained, competent and reliable staff.
This is infrastructure. Just like rail, power, water, Concorde, etc the gov is terrible at maintenance. Its not exciting, people take these things for granted until they stop working. On one hand you want them to sweat the assets to get the most value out of them but also fix/maintain as required. This is possibly linked to governments get confused about what is an investment and what is just spending.
Link: https://www.theregister.com/2025/02/10/legacy_costs_hmrc/
Just read the linked article -- you will get a better idea why recent waffle is just that....."We plan to do the impossible.....without the money or the resources".
Three step process:
(1) "We are doing something" ... Yup "something" in this case is publishing a plan which is clearly impossible!
(2) No money, no resources (see item #1)
(3) That's fine.....there will be another "crisis" next week......by then everyone will have forgotten about THIS "crisis".
I went to visit a US government establishment, to discuss some scenarios about the mainframe. They were not happy because the new boss person had been tasked with reducing the IT costs by 50% or more, and knew it could be done because he had set up a web server on his home Windows machine. He saw the solution was "to spin up utility hardware" (that is PCs you get from a PC store) when there was a demand for more capacity.
The IT guys I worked with did their own sums and said the amount of kit they would need would cost more than the existing mainframe - so no savings.
With the mainframe they had a down time of about 5 seconds of unavailability a year, processed 1000s of transactions a second and the response time was sub-second. They a backup site, and would regularly switch to it.
6 months later I got involved with a performance problem with the new environment. There were intermittent 10 seconds hangs many times a day and I could see it was a disk speed problem (in effect I had a trace of every I/O and about 10% had hundreds of milliseconds response time). The people who managed the virtualisation and disk farm said their stats were good.
I heard they solved their problems by doubling the size of disk farm, tripling the network capacity (to handle all the machine to machine communications), and disabling logging. At a huge $ cost.
I also know of another customer who moved from COBOL on CICS to Java on CICS (on the mainframe) for some parts of their business. They did a lot of planning and prep work - and the work came in on time - and budget. They started with a small, not critical piece, of code - and got that working - and learned many lessons from it. They then did a bigger project, applying the lessons learned etc, by the time they came to the critical code, they had a well established process.
It can be done.
Joke: How do you eat an elephant? A mouthful at a time. .... that applies to IT projects.
So you want to replace a legacy code-base written in COBOL on mainframes. Lets us enumerate the problems.
1) You lost the specs for the code base long ago and have not updated the few specs you have as you changed the code base
2) You lost the test-base for the code base
3) Your code base uses other software ... databases ... coms ... that are not supported in Linux and not understood or used outside the mainframe world
4) All of the vendor support of its software moved to India
5) No sensible CS student would even want to take a class in COBOL and the other mainframe tools. Thus the non-sensible folks you hire to do the conversion are not top notch.
6} Mainframes are 100s of times faster than 20 years ago so speed and capacity is not an issue.
7) A code base that is 50 years old is likely almost bug free.
8) Don't rewrite what is slightly broke. Imagine all the bugs that have already been fixed.
9) Learn the lost art of system integration.
10) Government has the attention span of a gnat, so the is no realistic long term plan.
So you propose to rewrite the code base from scratch
A more realistic plan would be to stay on the mainframe and rewrite individual components and new components in a high level language.
Continue to run all code on on legacy systems until it all works, then and only then, move to your favorite platform. This ain't a HW issue.
Don''t replace a component unless it runs on a test system in parallel with the legacy code for two years yielding the exact same results.
Don't try to improve new code till it matched old code. The problem is not how much you are spending on HW.
This post has been deleted by its author
It will never get solved, government IT systems, just like huge corporates will always be a series of half realised plans, cobbled together at the point where fantasy meets reality.
The fantasy is in the projects powerpoint slides, where incredibly complex systems are described in a handful of bullet points.
Much like government policy, there’s this “say it and it’s done” mentality, as if the words in the planning phases are all that is required, that the little worker people will make it all so like good little workers.
The reality is the complexity of not only legacy systems, but politics at the most petty. Little factions or tribes or silos that lurk within huge organisations.
Perhaps Mary with her team of specialists realises they’ll be out of a job as their tech gets replaced, so she throws a series of spanner’s into the works to delay and disrupt or John is hell bent on not implementing part of the planned solution as he reckons his team are already doing right so there’s no way he’s going to change things.
Projects massively overrun and management changes during the project are rife.
Plans are watered down and the project becomes one big crack filling exercise.
Imagine throwing AI into this mix?
So let's recompile our COBOL apps to run on one of the Windows-friendly implementations and shove them up Azure.
I mean, there are no other suitable platforms we could authorise to replace the legacy mainframes, are there.
Get an AI to create the web interface.
What could possibly go wrong?
I thought I was retired in 2018. I'd left various ancient languages on LI. I'd made it clear I wasn't looking for work, just meet people for beer.
An agency sought me out and asked me to come for an Interview (All the time I was looking for Jeremy Beedle and cameras)
They said I'd don't really well and were impressed with my knowledge of 80 column cards, magnetic tapes Z80 and Raspberry Pi.
A few days later a job offer. I politely said no thanks. They increased the rate.
I passed the lead onto a mate and he is happily fixing 50 year old code for ££££
I left a programming job 98 or 99 "Mainly Foxpro" and the next office was occupied by the company COBOL guy. He had been writing, maintaining and upgrading a system for a large steel factors for something like 7 years "IIRC it was upto 11MB in flat text format". I popped in for a visit some point during 2000 and was told he suddenly announced he had a new job and bailed out late 99. Turned out his god knows how many lines of COBOL was not Y2k compliant and he figured the job of fixing it could not be done in time.
Really, with things as they are in the worlds of IT and software development and Politics, there is little hope.
Hypothetical Ideal
Consider the ideal: a "Government.exe" that does all of government, all nicely joined up, interoperable, etc.
For such an ideal to exist, there'd have to be a solid understanding of what the requirements for it should be. However, you try getting politicians to agree what those requirements are, even within one party holding power for one term.
Also, such an ideal would be something of a behemoth; government.exe would not be a slim piece of code occupying only a few megabytes. So, it'd take a long time to put together. The trouble is that IT / software development and developers is a technology area driven more by "fashion" than anything else. "New" is cool and therefore essential, and often not backwards compatible with "old". For example, try getting Cobol and Javascript to interop at the level of calling each other's methods... So in the time taken to build "Government.exe", it is likely that most of the tech would have become unfashionable, hard to recruit for and it can never be completed.
The Software Development World May Become a Victim of Its Own Behaviour
The rush for AI is happening largely because the IT / software world has not embraced or catered for long term requirements, and has badly let down not just government customers but corporate customers too. For example, there's nothing actually wrong with developing / upgrading systems in the modern era in COBOL, other than it's not currently fashionable in the world of software development. As a piece of tech it still works, it's the people who refuse to.
Consequently, AI is pushing the "system implementation" language up to the level of "written English" - the requirements - and away from languages like C/C++/C#/Java/Javascript. You get your system implementation by telling an AI in English (or locally appropriate lingo) what you want your system to do, and it has a go. As soon as that becomes reliable enough - which is a long way short of "perfect" - Governments (and companies) will stop bothering to employ any developers at all. There won't be any reason to teach programming, IT, or anything, and the industry largely dies out.
There will be specialised fields in software that will remain the preserve of human developers, stuff where the source material to train an AI is thin on the ground (classified projects, or higly valuable proprietary things like cellular network stacks or flight control systems. What's interesting about these fields is that - very often - they're the ones that tend to have high demands for longevity and quality, and have customers who know enough about the implementation to know what it actually takes to deliver that (engineering customers, instead of managements or politicians).
What If AI Doesn't Get There?
Of course, AI might never get there, in which case Government.exe will remain a hypothetical ideal with no hope of it ever being achieved, unless things change. The maxim I have is that one cannot buy a bespoke technical anything from someone else unless one has a strong understanding of the technology oneself. One should be capable of building the system one is buying (i.e. you need to be time poor but knowledge rich). That'd mean actually employing engineers to be engineers on behalf of the Government / company. And to maintain an engineering resource, you have to give them things to do, which should probably mean "build the system in house". And by $DEITY there does need to be a properly powerful, all-seeing chief engineer role / department that can actually lay down the law on tech choices, languages, so that there's at least some chance of solving obsolescence problems once and once only, and can stop the adoption of "shiny, new" merely for the sake of it being exciting. (In some senses this exists - the Cabinet Office has a mandated web site design standard that is actually pretty good, templates provided. You end up with boring and dull websites, but they work, and they also work for people with accessibility needs. There is no room for web design in government websites, "pretty" is not a requirement).
And considering Gov is in charge of education curricula, and is paid by the tax payer to dispense training en-masse to millions who have no choice but to attend, you'd think that the requisite training for being a government software developer could be part of the education system. With that advantage there really ought not be a shortage of qualified programmers for government projects built using government standard tools. Companies like RR run their own education systems for their own advantage, why on earth can't government? Gov even has the luxury of legally mandating the training program ("You shall learn this and there is an exam you must sit").
The non-AI alternative is what we have today; unknowing customers (gov and corp) buying software they don't understand from developers who won't be there in 6 month's time. We know that doesn't work, not for companies and not for governments.
Examples
The only times I've seen systems successfully bought by non-expert government from outside is when the buyer has effectively said, "we've no idea, you define the requirements" and given the job to a team that really does get the tech and knows what can be achieved. Such projects tend to thrive because of the precious little oversight. We all know of such projects. The F117 was a highly successful procurement by the USAF from Lockheed's Skunk works at their very best. There were 2 people in the whole of DoD who knew about the project, had the money for it, and essentially left the highly experienced team at LMSW to get on with it. For SR71 / A12, and U2, it was basically the same. I've been involved in some here in the UK too.
I've also seen small-ish Agile projects involving UK gov appear to go well, only for it to turn out that the customer was keeping a requirement to themselves until late on in the project that completely invalidated the entire tech stack that they'd been quite happily approving of and paying for throughout. End of project, value = zero, bill = lots. Project Governance is also something that goes in fashions in UK gov; Scaled Agile Framework is the current buzz word, much beloved because it allows PMs to constantly report progress (which - very often - seems more important than actual delivery).
"Letting the Engineers Decide" won't work for all of Government.exe of course, because in a democracy it's supposed to be the politicians / voters setting the requirements, not engineers [Hmmm, maybe that's what's wrong with democracy...]. Yet, we all know what happened when Gordon Brown tried to turn the HMRC into an alternative department for social security with Child Tax Credits. IT fuck ups beyond belief had to occur many times over before that system even began to catch up with policy.
The UK Public Service seems no longer fit for purpose. I'm still waiting for a response to a letter I sent to HMRC in May concerning a payment of almost £5000 that has just disappeared - not credited or rejected, just taken.
I think continued COBOL use is a symptom of deep seated malaise and inefficiency, not a cause
My experience has been no training and cost-cutting. The systems are enormous, and one or two absolute heroes know the systems and only they can make any changes that might work. No one is trained, there is no documentation, and the latest laptops bought are generations behind what your home PC can do. Every large IT project planned has failed due to overly complex designs on outdated hardware.
I can see a lot of hard earned experience in the comments. Shame no one listens. If you could take that experience and inject it with a bit of youth and train it on new stuff, what a winner. Nah, it'll never work the management and politicians couldn't stand being told the truth.
