Government IT spending doesn't follow the same fiscal rules as your
basic household budget. It's not the case that the government has a
finite pot of money to spend and when it's gone it's gone.
Because, when the UK government hands it out to the private sector,
it gets the money back. All of it. Except, along the way, that money
gets exchanged in lots and lots of transactions which the government
skims parts off as VAT, Corporation Tax, Income Tax, NI contributions,
various duties, plus a million other levies.
If the government "saved" money by choosing efficient suppliers with
smaller headcounts and tighter cost controls it would cut off millions
from the treasury coffers. Taxes which are desperately needed to cover
the UK government's rising interest bill (debt is something like 95% of GDP as of 2025).
Huge behemoths like Fujitsu and Capgemini and IBM actually help to drive
the UK economy in its ever more desperate drive for "growth" (i.e.
greater tax revenue) and we can expect more, not less, wonga to be
unloaded on them to provide crude "value" from which those precious taxes can be distilled back out.
Hard agree. (2) is all about building out the test suite; once you have this (3) becomes a cake walk.
I've worked in a lot of places where end to end testing is performed manually by a SIT team who absolutely do not like to re-run a test once it's been passed. These people hate the idea of (3) and will overestimate the costs to the PM in order to avoid having to do it.
You can see two upticks in debt: first was the steady rise after the 2008 crisis (which austerity clearly failed to stem) and the second around 2020 which may be pure Covid or may be also due to a bit of Brexit.
When the UK government talks about "growth", it really means "growth in tax revenues". This means they want you and me to spend more because transactions are the drivers of revenue.
Inflation is generally painful for the public but very useful for a government up to its ears in debt because debt payments do not rise with inflation but revenues do.
And public services are highly toxic to an economy which requires 4-5% growth just to meet its debt payments. Why provide services for free when you can collect VAT receipts for basic essentials like clean water, energy, and medication? Why spend millions on regulatory oversight when the inevitable health issues downstream will result in more private spending and GDP growth?
You're not thinking like an economist :) Here's something I saw on Twitter (no source):
The bicycle is the slow death of the planet.
General Director of Euro Exim Bank Ltd. got economists thinking when he said:
"A cyclist is a disaster for the country's economy: he does not buy cars and does not borrow money to buy. He does not pay for insurance policies. He does not buy fuel, does not pay for the necessary maintenance and repairs. He does not use paid parking. He does not cause serious accidents. He does not require multi-lane highways. He does not get fat. Healthy people are neither needed nor useful for the economy. They don't buy medicine. They do not go to hospitals or doctors. Nothing is added to the country's GDP (gross domestic product). On the contrary, every new McDonald's restaurant creates at least 30 jobs: 10 cardiologists, 10 dentists, 10 dietary experts and nutritionists, and obviously, people who work at the restaurant itself." Choose carefully: cyclist or McDonald's? It is worth considering.
P.S. Walking is even worse. Pedestrians don't even buy bicycles.
Back when he was still considered quotable, Dominic Cummings often mused about the UK's future post-Brexit. I seem to remember his blog mentioning data science and drug research as possible areas where UK could build a global advantage.
I can't be bothered to wade through it all but if you're interested his (old) stuff is here: https://dominiccummings.com
Even if the organistion is fully signed up to the knowledge building philosphy, it can still be derailed if the staff aren't up to scratch.
Around 12 years ago, my employer tasked me with building a quote engine for a new product they wanted to sell online. The engine needed to produce 4 additional quotes (2 lower, 2 higher) to either prevent potential walk-aways or to offer upsells to capture potential additional revenue.
And it struck me at the time that this sort of hand-wavey selling tactic would be just the sort of thing that was likely to change so I put all this logic into a pure function - pass in an original quote request and the function returns a collection of alternative quote requests.
And, sure enough, a couple of years later, the business decides to change the approach and offer 1 lower quote and 3 upsells. And they give the job of implementing this to another developer.
I was still at the company and was known as the original developer (my name was in a comment at the top of the file, for a start) so I was asked to review the code changes.
I was surprised to learn that the other dev had left the pure function untouched and had, instead, written a bunch of new logic to generate the alternative quotes. Not based on the original quote request but on the collection of alternative quotes returned from the original function. Furthermore, this new logic was placed in main procedure - mama's finest spaghetti in the making, right there.
So I rejected the change and told the dev where to put the actual logic. Then I waited for the re-review request to come in.
What happened instead is that the code went live anyway - the dev had simply re-raised the review request and assigned it to another dev who rubber stamped it.
Looking back, I don't think all the documentation in the world would have prevented this behaviour. A better approach would be for the company to pass the changes to the original developer and to pair with another dev - like Fred Brooks' Chief Programmer plus Assistant recommendation.
I was never approached for an end of year review for this developer and I left the company before them. It's not personal but I'll resign on the spot if a company I work for employs this developer in future.
I have 3 kids and have been to visit A&E countless times over the years. I always note the hand written checklists stuck up in the walls of Triage and wonder how many of these were derived through trial and error and which were introduced by more experienced medics.
For some reason the fact that they've obviously been produced locally gives me more confidence that they've done the hard yards; professionally printed ones would instead make me think they're only up there because management wanted to raise awareness.
I recommend the book Treasure Islands by Nicholas Shaxson. It covers offshore tax havens and the central role played by the City in facilitating capital flight and tax avoidance. Chapter 12 is devoted entirely to the City of London Corporation.
Haven't read it for a while but I do recall the word "strange" appearing a lot.
We can assume that Twitter was a vocal opponent to the repeal at the time and that they have now become somewhat more in favour if it means knocking out their competition whilst they enjoy special protection.
All it would take is some catalytic content to kick things off and a compliant state judiciary to get the ball rolling.
Bluesky's Terms Of Service explicitly state that they are not liable for the impacts of their user's content. They say they reserve the right to delete content or accounts at any time at their discretion. And then there's this:
Indemnity: Summary: If someone brings a legal claim against us based on your actions on Bluesky Social, you are responsible for our defense in, and the consequences of, that claim.
It all looks bulletproof on the surface but I just don't know if it will survive under Trump/Musk.
> Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.
Silo-isation compounds this. If the maintenance costs are borne by another team or if any rework will be funded out of a different project, the managers are not going to care about quality beyond the basic "signed off by uat".
There was a detailed proposal to introduce encoding/json/v2 last year but I don't know how far it's progressed since then (which you probably already know about but mentioning it here for others):
The flaws in the sewerage system are fundamental and pervasive. It would be a national multi-generational effort to rebuild it all. It's going to be far cheaper to simply make swimming outdoors illegal and alter insurance guidelines to deny claims for water-borne health issues.
Stuff like this appears in UK newspapers all the time. It's just the think tanks putting controversial ideas out there so that public outrage can be gauged. This then informs government policy going forward.
However lavish or detailed or faithful to the Gibson Vibe this adaptation turns out to be, it will live or die on its realisation of Molly Millions, the baddest badass take-no-shit progenitor of Lisbeth Salander, Lara Croft, and The Bride.
It feels like there's a tiny bit of conflicting advice in this. There's the "not rocket science" rule which results in "no CI-failing commits on main" and then there's this:
> Third, our review process is backwards. Review is done before code gets into main, but that’s inefficient for most of the non-mission critical projects out there. A better approach is to optimistically merge most changes as soon as not-rocket-science allows it, and then later review the code in situ, in the main branch.
But the tip about adding a failing test as a separate commit on the feature branch wouldn't survive a merge and it wouldn't live long enough to be reviewed either.
I like most of the advice in this article but this review one is giving me pause.
Maybe we're coming at this from different ends? I've always adopted the position that the database is the source of truth, not the ORM data model. I've always maintained that mirroring the database schema in an ORM data model is an anti pattern. And I don't like exposing tables to client code under any circumstances -- a view for queries is an absolute minimum and for updates I prefer to implement those through stored procs.
There's nothing stopping anyone from writing their own DAO layer with bespoke SQL statements and allowing intellisense to index the API over the top of that.