If you want to understand how the legal system made it so easy for the Post Office to destroy the lives of the sub-postmasters and sub-postmistresses – and how the legal system then made it so hard for them to obtain justice… read this by David Allen Green.
|
|||||
|
We are developing the social individualist meta-context for the future. From the very serious to the extremely frivolous... lets see what is on the mind of the Samizdata people. Samizdata, derived from Samizdat /n. - a system of clandestine publication of banned literature in the USSR [Russ.,= self-publishing house] Authors
Arts, Tech & CultureCivil LibertiesCommentary
EconomicsSamizdatistas |
Understanding the Post Office scandalJanuary 13th, 2024 |
 13 comments to Understanding the Post Office scandalLeave a Reply |
Who Are We?The Samizdata people are a bunch of sinister and heavily armed globalist illuminati who seek to infect the entire world with the values of personal liberty and several property. Amongst our many crimes is a sense of humour and the intermittent use of British spelling. We are also a varied group made up of social individualists, classical liberals, whigs, libertarians, extropians, futurists, ‘Porcupines’, Karl Popper fetishists, recovering neo-conservatives, crazed Ayn Rand worshipers, over-caffeinated Virginia Postrel devotees, witty Frédéric Bastiat wannabes, cypherpunks, minarchists, kritarchists and wild-eyed anarcho-capitalists from Britain, North America, Australia and Europe. CategoriesArchivesFeed This PageLink Icons   |
|||
All content on this website (including text, photographs, audio files, and any other original works), unless otherwise noted, is licensed under a Creative Commons License. |
|||||
Not a hell of a lot to be said about this, other than to observe that it’s another one of those cases where the “expert class” has fallen prey to their own epic delusions of grandeur: “Of course the computer can’t be wrong… We experts wrote the programs…”
Objectively, they were wrong.
What strikes me as odd, looking at this from this point here in the future from where these things took place is this: Where the hell was the paper trail? Surely, if these postmasters were to be accused of these fiddles, there had to be some other proof besides the Post Office’s own accounting system? As in, where’d this money go, once it was peculated? If you can’t show where the errant postmaster deposited the funds or spent them somewhere, how the hell can you prosecute?
I’ve dealt with these financial issues before, back in the dark ages. My bank account was overdrawn, a few checks bounced. As a young soldier, that was something of an issue for my bosses. I had good track of my money, or so I thought, and there was plenty of cash in my account. Go to the bank, inquire, and am informed that, no, there was not enough money because I’d taken money out with my (then very new and unusual-to-have…) ATM card. Which I did not possess, my bank account being checking only. The bank insisted I’d taken the money out, continually saying “But, the computer says…”, and I kept pointing out that I didn’t have the card to have taken that money out with, per their entry on my account register. End of the day, I got my bosses involved, they couldn’t make any headway, either. Demanded to see where I’d ever been given an ATM card, they couldn’t do it, and still refused to admit that they’d made a mistake. Never got satisfaction on that issue, and I’ve never done business with a bank since. Credit unions are usually a lot more responsive, here in the US.
The point to be learnt there is that so long as money is merely an entry on an electronic balance sheet, there are almost always going to be errors. Prosecuting people for those errors strikes me as a bit of an overreach, unless it can be proven they actually did something like actively fudge the numbers.
My first thought is that our way of life and that of our descendants, is going to be comprehensively made worse by the software that is used to predict Global Warning / Climate Change. This software is nowhere near the standard of the Horizon software. It is designed to predict the required catastrophic outcomes that are necessary to achieve ultimate control over all but the so called elite. Perhaps there should be a TV drama about this scenario, but I doubt that the compliant, corrupt media would do it with the prospect of losing their ‘hush money’
Let me offer a different perspective on this. The contractor that built this, ICL, is your typical large government contractor — incompetent at everything except lobbying government officials or quango leaders in this case. This system cost nearly one BILLION pounds. If my company were writing this it would probably have cost maybe five to ten million pounds, plus the cost of hardware out to the post offices and training (probably another 50 million on top of that) plus some sort of annual maintenance cost. It is an utter disgrace, and reminds me a lot of the whole Obamacare web site debacle.
However, (and here is the different perspective), why were ICL not punished for producing a system that was evidently bristling with the most basic of bugs? An accounting system that couldn’t add up a column of numbers? It seems obvious to me that they made very little effort to properly test this. And the utter failure of the quango contractor redounds to the users who are victimized for the failures of ICL? This seems to me to be about butt covering for the most egregious failures by the people who managed the contract.
And, I might add, the fact that ICL didn’t have a very large effort post deployment to monitor and correct problems with the system, that apparently the users were reporting in abundance — I mean it is shocking beyond measure.
Did anybody get fired for creating a system that is apparently utterly riddled with bugs? Of course not, no doubt they got promoted.
And why the hell do we even have a monopolistic post office, when the country is bristling with other delivery services? Can you imagine this happening at FedEx? Of course not.
“Did anybody get fired for creating a system that is apparently utterly riddled with bugs? Of course not, no doubt they got promoted.”
Almost certainly promoted, as Fujitsu/ICL continued to (and still does to this day) gain large and lucrative government IT contracts. Fujitsu/ICL is a fundamental building block of UK State IT infrastructure, and as such is too big to fail, or be punished. They cannot throw it into outer darkness as to do so would crash large electronic parts of the UK State apparatus. It is untouchable.
Fraser, as someone who has had to deal with the UK branch of FedEx in an IT-related context, I absolutely could imagine this happening with them.
Turbulent Times blog also covers this today. Deals with the Law Commission and the repealed the 1984 law.
@ Fraser, for IT projects this size, the purchaser normally does extensive rounds of UAT (User Acceptance Testing) as part of signing off that the system was fit for purpose. I’ve done this client side and vendor side.
The point being it is incumbent on the purchaser to test to make sure that the system functions as per the stated requirements.
What happens in practice is that (even for big systems) requirements are surprisingly often poorly defined, ambiguous and often contradictory. Also, with badly run projects, time and budget become issues, and one of the things that organisations are often willing to de-scope is UAT. In parallel, the executives who signed off on the project have all moved onto other priorities, so you have a thing called “absentee management” where the management of the project is left to underlings who simply may not be competent to oversee a complex project like this.
Compounding the problem, its not uncommon for the vendor to, um, second guess what the client really needs. EG, this is a “ticketing system” and use proxy logic in the design. (Ticketing systems do this, well the last couple we built did this, so this system needs to do this). Not to mention that when the pressure is on at the vendor side, the second thing to go is testing, to the point that things get chucked over the fence and developers wait for the screams of outrage. If none follows, well, job done. Thats where UAT becomes vital.
Another common compounding problem is that the purchaser often does not know what they want or someone (often) makes sweeping decisions about functionality without fully considering the implications. So you end up with functionality that does not reflect the legacy process. This is common, as organisations often are seeking to streamline or enhance their internal processes. The problem is that it is very hard to write effective UAT scripts for complex new processes. On many occasions I have seen the client turn to the vendor and ask them to write the UAT test scripts. Thats asking to get rogered.
Then finally, we get to the “double down” game. I as the vendor priced your requirements, often knowing that there will be change requests (for new of different functionality). Change requests get approved by the business and passed on to the vendor. Then one day at a governance meeting, the vendor say “fellas, our take is we have built 25% of the functionality, but consumed 60% of the budget”. Lets say thats 6 million spent. The Client manager then has to decide, stop the project and own up to a six mil write off (never happens) or he goes and finds the budget. Which has gone from the original 10 mill, to say 15 million. On we go, all slaving away, everything going great. More change requests.
Several governance meetings later. “Ahem, fellas. You have given us several complex change requests. We have spent 10 million to date, and we estimate we are about 50% done. we suggest you re-forecast for the project to come in about 25 million. Much wailing and gnashing of teeth, but the decision for the manager now is own up to a 10 million write off or, and this is where the fun starts, lets start de-scoping the project. Arbitrary decisions start getting made to drop functionality, with often little consideration of the implications, UAT being an easy one to cut back on. A smart client manager meanwhile has got himself a new job or promotion so is no longer responsible for the developing train wreck. A new manager gets dropped in and “boom” gets hit straight away with another request for an increase in the budget to 35 million. They dont want to start their new career with a disaster so they go and find the money, arguing that they got handed this pile of shit.
So the 10 million project is now at 35 and counting. Corners start getting cut all over the place, more random and poorly considered decisions get made.
Eventually “something” gets delivered. Or not as is occasionally the case. This is how these situations develop.
@SkippyTony, sounds like you have been round the block a few times. I have seen all the things you mention many, many times. Nonetheless it is pretty much what I was saying. All these dysfunctions are a consequence of shockingly poor management. I do this stuff for a living and this is so bad it makes my skin crawl. It always happens and the bigger the vendor or the bigger the customer the worse it is. Without proper management problems grow exponentially with project size and length of communication and decision channels. However, these problems can be managed by well known methodologies. So it is entirely the fault of the people in charge.
Moreover, in any any specification there are some things that a are implied and not explicitly stated. For example, this spec probably didn’t have a line item saying “System will add a column of numbers correctly according to the standard rules of arithmetic.” Nonetheless, I think the client might well expect that is assumed. It seems from what I see the problems weren’t some unusual code path wasn’t right, or some GUI layout was ugly, or some calculation didn’t take into account some special accounting rule. These sort of things you expect to shake out from testing and at the worst user acceptance testing. However, this system seemed to fail at its most basic functions, nobody noticed and there seemed to be no effective post deployment tracking of bug reports of this kind.
Missing a few things is UAT is one thing, really it is something to be expected, and something to be aggressively managed, but it seems that the level of failure of this project is off the charts. And worst of all, the people responsible (the management team) not only blamed the users (which isn’t uncommon) they actually sent the users to JAIL!!! Ever had a project go that badly wrong? Fortunately I haven’t.
This project should be written up in a book called “How to cock up a project worse than any project has been cocked up in history.”
Though in retrospect, perhaps that is a bit of an overly optimistic title.
Has there ever been a large complex software system whose development didn’t have massive, massive issues?
I can’t think of any, off the top of my head. Every single one that just works that I’m aware of has evolved slowly, over time, from much smaller projects. The guys who set out to replace entire systems, as in the air traffic control network, usually wind up blowing the whole thing up.
I could stand correction on this, if anyone knows of anything big that’s actually come off without major issues. They’ve all been about like the F-35’s new-age logistics system, which I understand has now been replaced, with the replacement still exhibiting what they politely term “Issues”.
I’ve been involved in a few larger legal projects for government. I’ve also been involved in a few construction projects for government.
The situation that SkippyTony describes arose in almost all of those projects.
I think the common denominator is government. No accountability. Screw things up, and they move you up and over.
I think there’s a large chunk of outright hubris involved, as well. The systems I’ve personally observed crashing and burning, mostly around the military, were all things that seemed to be driven from “on high”, the people at the top layers of the hierarchy. Who’re usually either completely out of touch with the real needs down where the stuff is getting deployed, or were idiots all along…
I think the whole thing just comes out as more proof for my theory that humans do organization very, very badly. It’s a generic trait across all cultures and civilizations, it would seem–The precise wrong people gravitate towards power positions within the hierarchy, and then once they’re in them, proceed to munge everything up.
Top-down anything works very poorly in all circumstances. You don’t get good results when the “managerial class” is setting out the needs statements, and a lot of the time, they’re focused on the things that just don’t matter.
Case in point… Minor one, but still: We had a nice little Microsoft Access database going in Iraq for tracking IED events. It worked well enough that it lasted through the two subsequent rotational deployments, and when we went back for our second helping, it was still in use, although being supplanted by this new product that came out of JIEDDO. Interesting thing, about that “new product”? It was an unusable POS that reputedly cost a couple of million dollars. We’d submit trouble tickets with it, but they’d never act on them, and from what we could see, the primary focus was not on tracking and identifying IED trends, but on making it easier for the staff using it to produce nice, pretty PowerPoint charts… According to the one guy we talked to who’d been involved in the design work for it, they spent more time worrying about the colors of the data fields on the input screens than they did making sure the data could be gotten at in a timely manner to do analysis with.
And, of course, who drove that train? Not the kids doing the data entry or the reporting, out in the field: It was the full Colonels back up in Baghdad and CENTCOM who made all the interface and data collection decisions.
When we left Iraq, we were still using the improvised Access database that we’d built initially back in 2003 as a kludge; that, at least, allowed you to get at the data to do actual work with.
Any time you get above user level, they tend to screw these things up. I’d wager good money that Fujitsu and the rest of the people that screwed up that software never once consulted with an actual postmaster, or talked to one about what they needed.
@Kirk
Has there ever been a large complex software system whose development didn’t have massive, massive issues?
Yes, many, many projects go along with fairly minor issues. I have worked on hugely complex medical systems that developed with appropriate management techniques and they go very well. Not without issues of course, every project has issues. The question is how well are the issues managed and do they snowball out of control.
And I have to say this project does NOT seem all that complex to me. Some of the projects I have worked on for example involve lots of extremely complex image manipulation or signal analysis. This post office thing is an accounting system in essence, with many relatively simple functions. FWIW the major challenges in these sorts of project – with many features all of which are fairly simple — usually come down to requirements management (as SkippyTony mentioned) or integration issues with other systems. And these integrations are generally also management challenges rather than technical challenges. These also include change management — which SkippyTony mentioned also.
So, Bobby is right here. It is not the nature of the project that makes it a disaster, it is the failures of the management. And it is exactly what you expect from bloated bureaucracies, with tenuous accountability.
Every single one that just works that I’m aware of has evolved slowly, over time, from much smaller projects.
You are right. This is precisely how these sorts of projects are managed correctly. You get a working system with minimal functionality, then you add functionality piece by piece with constant review and feedback from users as you go. And when you run out of budget you have an 80% system, which is usually good enough, because 20% of the ideas you had originally were dumb anyway and they can always be added later if you like. However, this is not something conducive to your typical bureaucracy. They want a massive document with a hundred appendices, carefully costed for each line item. This approach has been proven over and over to not work, but it is all massive bureaucracies are capable of.
Yes Perry – it is not just the American legal system (Civil and Criminal law) that is a mess, the British system (both English and Scots law) has been messed up as well.
I remember Dr Sean Gabb (yes my old foe – we had so many disputes), CORRECTLY pointing out that the justice system was being corrupted even in the 1980s – and it has got vastly worse since then.
As for this specific area – many people knew the Post Masters(basically little shop keepers) were innocent – I remember Andrew Bridgen M.P. telling anyone who would listen that they were innocent, and he was doing that in 2014.
But as with Covid “vaccines” there is a difference between what most Members of Parliament say privately and what they say publicly.
Many Members of Parliament knew for years that the Post Masters were innocent, but they did not say so in public (fear of the system), just has many Members of Parliament have known, for a long time now, that the Covid “vaccines” are not very “effective” and were certainly not “safe”.
What is different about someone like Andrew Bridgen and the rest of us? The difference seems to be that most of us do not overcome our FEAR (people in politics are filled with FEAR – we can have our positions taken from us at any time), whereas he does overcome his fear – on Post Masters and on Covid “vaccines”.
He has more courage than we have – because he makes a choice to have more courage.