In this episode, we look at the Post Office Horizon scandal, an app that caused what some people are describing as the largest miscarriage of justice in British legal history.
We look at some bugs, the legal judgements and what might have gone wrong at the Post Office to allow things to go so off track. I analyse what we can learn from the disaster to help stop this from happening in our own projects.
Resources used to research and compile this podcast include:
Judgment and related docs:
The Great Post Office Trial
Panorama : Scandal at the Post Office BBC Documentary 2020
Post Office worker 'wrongly jailed for £59,000 fraud caused by computer glitch'
The Post Office Horizon IT scandal, part 1 – errors and accuracy
House of Commons, Chi Onwurah MP
Peter Houghton (00:00):
Hello. My name is Peter Houghton and welcome to investigating software. This is a story of a buggy software system that ended up with the prosecution of hundreds of its users and pushed many more into bankruptcy, depression, and ruin. It's the story of the Post Office Horizon system for an idea of the scale of the issues. Here's MP Chi Onwurah.
Chi Onwurah MP (00:21):
Mr Speaker, the Post Office horizon scandal may well be the largest miscarriage of justice in our history, 900 prosecutions, each one, its own story of dreams, crushed careers, ruined families, destroyed reputation, smashed and lives lost, innocent people bankrupted and imprisoned.
Peter Houghton (00:45):
Horizon is an EPOS or electronic point of sale system that's used in every post office across the UK. When you go into a post office to say by some stamps or deposit benefit cheque or even buy insurance, the Post Office teller is using the Horizon system to make those purchases. He also keeps track of stock and updates the branch accounts for every purchase in late 2019, the Post Office settled a class action or group litigation brought by subpostmasters for 58 million pounds in the high court in London, that's over 71 million US dollars or 64 million euros. In fact, the costs on all sides are high we've Justice Fraser, noting that the sides had spent 27 million pounds. This is in legal fees and expenses. And in his words,
Justice Fraser (Acted by Peter Houghton) (01:35):
Both this level and rate of expenditure is very high, even by the standards of commercial litigation between very high value blue chip companies.
Peter Houghton (01:44):
So who are these rebellious subpostmasters? They are the people that run local and often provincial post offices. The sort of post office doubles as a village shop, I would have sold your Sunday newspaper and a pint of milk, birthday cards, that kind of thing. The sub postmasters operated under contract with the Post Office. And so sat in an awkward situation where they were sort of users and also in a sense customers of the horizon system, but technically they're also independent and responsible for their own branch accounts. And it's that point, the fact that they were responsible for balancing the books, but critically didn't have any direct input or control of the tools Horizon, for example, that lies the crux of this scandal. It wasn't until justice Fraser ruled in an earlier trial, that sub postmasters were not liable for the accounts unless the Post Office could prove that they were at fault.
Peter Houghton (02:36):
So what was the lawsuit all about? Well, the judgment and related documents provide a treasure trove of information regarding what went wrong at the Post Office over the previous 20 years in 1999, the Post Office rolled out a new point of sale system Horizon to all post offices. The system had to cost a billion pounds so developed and had been several years in the making. In fact, there were trials of the system as far back as 1995. Soon after the system went live Fujitsu, the supplier who developed horizon and the Post Office received reports of discrepancies and disappear in cash at post offices. I can imagine they sort of expected this. I mean, with any large deployment, especially when it's as complex as this, there's always going to be a few issues that crop up after go live. What's puzzling is how the Post Office treated some of the people that saw problems with Horizon.
Peter Houghton (03:25):
Now the Post Office isn't like other companies, for a start it's state-owned and has its own investigators, and it can prosecute people. It deems to have committed a crime. In fact, back in the cold war, it was involved in the investigation of Russian spies and even took a role in the hunt for the perpetrators of the great train robbery. In 1963. When I first heard about the investigators, I had assumed wrongly that they were a pretty minor operation, the sort of thing that operates out of a small basement office consisting of a couple of retired police, or maybe a sort of a Colombo figure who slowly investigates these odd issues. But in fact, as of 2010, so right in the middle of the horizon scandal, there was 287 investigators in the Royal Mail Group that would investigate issues across the post office and the Royal mail.
Peter Houghton (04:10):
The Royal Mail is the organization actually delivers the letters and parcels, unlike the Post Office, which is the shop where you cash checks or buy stamps. So like every organization, with a lot of hammers or investigators in this case, the Post Office decided to treat a lot of these bugs as nails over the now 20 years, since the first deployment of horizon, hundreds of people have been prosecuted by the Post Office for crimes such as fraud or false accounting. Some ended up in prison and many been financially ruined as the post office, forced them to pay back the money that was allegedly missing from the accounts. The trial judgment provides a fascinating view into the problems with the horizon system and the arguments made by the post office and the subpostmasters as well as fidget. So the documents include a detailed description of the bugs often, including recreation steps and a description of the impact from the post office and the Fujitsu staff who investigated the issues. Here...
Peter Houghton (05:07):
I'm going to outline three of the bugs from the judgment. Now it's only free because if I did all of them, that'd be 29. And that would probably take too long and test your patients. But these three are quite indicative of the sort of issues people were seeing with the application.
Peter Houghton (05:20):
23. Bureau to challenge currency conversion is available over the counter in many post offices. And as you'd expect, they have a big electronic board on the wall that allows you to see the exchange rates you can get for each currency. Unfortunately, these boards didn't always display the exact same values as those used by the horizon system itself. When you buy currency, the differences were rounding errors and were only present in the fifth or sixth significant figure, but obviously the impact becomes more noticeable with larger purchases of currency. The lack of rigor here is typical of the bugs that are listed in the documents.
Peter Houghton (05:56):
In fact, justice, Fraser States this and his judgment about this bug. This plainly shows a complacent, if not lackadaisical attitude to financial precision. The record show that this bug was occurring in 2005, 2006 and 2010 onwards. Interestingly, the post office decided this was not a bug as there was one report of a similar bug that actually turned out to be due to human error, but justice, Fraser notes,
Justice Fraser (Acted by Peter Houghton) (06:27):
The entries above make it clear that there is a bug. The very word chosen by the Fujitsu employee who wrote the two known error logs is 'bug' to see this characterized in submission as there not being a bug and being evidence of human error is not only puzzling but flies in the face of the terms in the Fujitsu to documents. I find that this is evidence of a bug
Peter Houghton (06:53):
4. Dalmellington bug. This was probably one of the worst books and one of the ones that would be most easily caught by a skilled software test engineer in certain circumstances, an old transaction screen might display after I user had logged off and logged on again. When that happened, the old transaction could be displayed with the enter key being enabled by default, a confused or impatient user. I've heard that those exist, might hit the enter key button in an attempt to clear the old transaction away depressingly this didn't clear the screen straight away and actually resulted in the old transaction being repeated. In one case, the sub postmaster hit the button three times causing a total of 32,000 pounds to get transferred. That's the intended eight grand transfer plus an imaginary 24,000 now missing from the branch accounts. As you can see, this is a cascade of errors on the part of Fujitsu and the post office.
Peter Houghton (07:51):
Firstly, the log off and log on process did not correctly clear or even complete the first transaction. Secondly, the transaction was displayed again, defaulted to the enter button. Thirdly, the user is able to send a transaction through multiple times by tapping the keys repeatedly. Now, if you think about it, when you use a modern website, even, you know, not mainstream website, it's quite common for it to block you from pressing a key multiple times, even these kind of small time sites block that functionality because they know it's a risk because they don't want to have to chase up these multiple purchases. This bug was present for six years, between 2010 and 2016. And Fujitsu's own records show that just between 2010 and 2014 alone, they were 93 instances of the bug. And none of these resulted in calls to the support desk by sub postmasters. I suspect that even the sub postmasters were unaware of the bug or were reluctant to call the support line for whatever reason,
Peter Houghton (08:48):
3. Suspense account bug, a suspense account is a sort of temporary table used in to hold information before it's properly assigned. The horizon system was in part an accounting system, as well as just an EPOS or electronic point of sales. And it had its own local suspense account. Unfortunately, this suffered from a bug Gareth Jenkins. The lead engineer from Fujitsu is quoted in the documents as saying.
Gareth Jenkins (Acted by Peter Houghton) (09:14):
The root cause of the problem was that under some specific rare circumstances, some temporary data using calculating the local suspense was not deleted when it should have been. And so it was erroneously reused a year later,
Peter Houghton (09:27):
This somewhat scary bug was present between 2010 and 2013 Justice Fraser goes on to state.
Justice Fraser (Acted by Peter Houghton) (09:36):
One branch had a loss of approximately 9,800 pounds, some were 161 or less and another at a gain of 3,100.
Peter Houghton (09:46):
I could quite literally go on for hours describing the bugs with horizon, but I'll stop there for now. At least. I might return in a later podcast. There's just so many bugs. As always. I'll put a link to the judgment and any other relevant facts in the show notes. So you can look these up yourselves.
Peter Houghton (10:06):
As I suggested at the start, hundreds of people have had their lives ruined by a system, provided to them by what was once a venerable and trusted service. So I guess the question is here, how did what is essentially a dodgy it system result in so many people being prosecuted and ultimately this huge class action costing the post office, millions of pounds. Why didn't they just investigate the bugs, fix them and apologize for the inconvenience. In my opinion, from looking through these documents and hearing the victims, describe their ordeal, it really comes down to a problem in the culture of the Post Office and Fujitsu. They didn't respect their users. And when they reported the same areas over and over to the support lines, they were told by the Post Office that they were the only people that had seen the problem that they were at fault.
Peter Houghton (10:51):
And if they didn't make good, the missing money they'd be prosecuted. I don't think the post office saw the bug reports and confused subpostmasters phone calls as valuable feedback. They maybe saw them have an embarrassing mistake, something to be hushed up or punished this sort of blind allegiance to the ideal of the software. Isn't that rare? I've worked on a couple of companies where the app, or at least the idea of the ideal working app get confused of what the team has actually delivered. One of the best examples of this I've seen is when a large team I worked with hired an external consultancy to do a series of load and performance tests. After finding out that the app couldn't take the load, they started trying various other load tests and different load levels, looking for a working or passing test, understandably. They were looking to see what the app could handle, what can it do at least, but very quickly though, they slipped into a mentality where instead of trying to find the cause of the problems, they were searching for a way to get the load test, to prove that the app was able to handle the load, which of course it couldn't, it's like in their, they were thinking like, what is wrong with this consultancy?
Peter Houghton (11:56):
Why can't they just show it's a solid app? They're clearly no good. In my opinion, having this kind of blindness as well as an existing culture and literal, whole department for prosecuting users of the system, made it all too easy to slip into a us versus them. Culture us good, them bad. As soon as this mindset becomes commonplace, the company stops listening to the information they're getting from the support desk or QA or error logs, the company stalls. And it's just a matter of time before they crash. In my opinion, it's probably very difficult to stand up and say, there was a bug here. We've got it wrong. Let's just fix this at the Post Office. And probably got a lot harder after dozens of people have been prosecuted while this is an extreme example. I don't think that kind of attitude is that rare just in lesser degrees in software and maybe any complex system or bureaucracy, we tend to separate the actual system behavior from what it is meant to do.
Peter Houghton (12:49):
We might think we have a state of the art data processing application, but what we actually have is some lines of code that might not even compile in software investigation and testing we describe what the system does, not what it says on the label, not what we think it should do. We describe what it does do. So how do we avoid this sort of broken mindset? I start by trying to be humble except that we've made mistakes. Even if we have no evidence of those mistakes yet they'll come. In fact, a lack of evidence probably indicates a lack of testing or at least a lack of imagination in those doing the development and testing. This sort of expectation can come from experience. That's often that sort of painful experience. One the hard way by seeing what you thought was a great application, turn out to have many bugs.
Peter Houghton (13:35):
And that can be for people investigating bugs, testing or core developers themselves. That's not to say it couldn't be taught. We often make the mistake of ignoring the things we got wrong, or actually they're one of the best ways to learn. We can actually spread that knowledge in a company. So not everyone has to go through those hard lessons before we learn from those mistakes. What else? I try to reverse the game instead of denying bugs and moaning that they weren't caught earlier, or why weren't they caught in unit testing that genuinely discourages people from owning up to bugs or spending the extra time to almost find about cause you know, I'm only gonna get moaned at, try the opposite approach because remember if we let other people know that these sort of bugs can happen quite easily and how they happen, we can help avoid them in future.
Peter Houghton (14:21):
So not everyone has to go through this pain. So try and end up with your team competing to find issues, to find problems, create a sort of sportsmanlike approach where it's sort of a gentle arms race, polite arms race, where people trying to show that the app is more testable, that we've found some cool new bugs and that we can expect these sort of failures. If we're not careful commend your team when they uncover a mistake or a bug or a risk that way, instead of dreading a bug report and frowning people say, awesome, stick it on the board. You know, this is great stuff. We can fix that tomorrow. Now this isn't a magic recipe, but it's a start. It can help break the downward spiral. That many things are stuck in becoming more focused on quality. Won't divert your team from delivering. In fact, quite the reverse they'll deliver better.
Peter Houghton (15:04):
There'll be more focused bugs, easier to find an easier to fix and easy to test for you and your team are gonna end up having greater faith that the serious issues have been caught and you can ship after a while. Risk becomes something you look for almost subconsciously. You're better able to allocate your time. You write defensive code by default, you use rigorous debugging techniques and you're constantly testing the app before and after go live as well as talking with customers and product owners. There just a few tips that I think maybe the Post Office and other organizations could have used in the early days here helped to avoid a lot of the pain, heartache and financial harm that all sides have come to here. Thank you. You've been listening to investigating software and I'm Peter Houghton.