ᗷIOᑎIᑕᗷEᗩᖇᑌK

For the greater part of my career, I have worked for software/solutions vendors and can see a few parallels between my experiences in software and the post-office scandal in the U.K.

While I cannot understand how, between Fujitsu and the Post Office, this situation was allowed to happen, I can imagine some of the personalities involved that led to this happening. Not that of people at the top, but the project managers at Fujitsu and the Post Office.

In the software domain, perfection is an elusive goal—every notable software solution harbors bugs or defects, irrespective of how meticulous the development process may be. These issues, whether deemed bugs, defects, or mere issues, signify failures in technology, functionality, or hardware. Their impact can range from significant disruptions for users to minor annoyances. The diligent efforts of software engineers and testers aim to identify and rectify these imperfections before software release, yet invariably, some slip through the cracks.

Generally, in the first few days, weeks and months of software ‘going live’ or being ‘launched’, the number of issues will be higher than you would expect; the first-time users get access to the system and do their day job will put a system under stress, and sod’s law says they will find issues with it. The stress imposed when users engage with a system for the first time often reveals unforeseen challenges. This phase is crucial, as it sets the tone for the software’s perceived quality and performance in the real world.

In my previous role, I encountered a peculiar figure—a self-styled “Delivery Director” with a demeanor that immediately put me on edge. His discriminatory views surfaced when he insisted I refrain from direct communication with a client, citing their purported lack of proficiency in English, a claim debunked by the client’s impeccable English skills. This prejudiced attitude was my first red flag, setting the stage for subsequent concerns.

This individual’s defensive behaviour reached disturbing heights when he accused a client of dishonesty, vehemently rejecting a legitimate bug report. While being addressed, his deletion of bug reports from the tracking system further exacerbated the situation. His unwavering stance on the software’s infallibility jeopardised client relationships and compromised the software’s quality.

The stance that the software was bug-free was really concerning for me; I’d never seen anything like this before. It made me feel ill; this behaviour is not conducive to a good relationship with the customer, and it left bugs unfixed in the software, actively reducing its quality.

Eventually, this all came back to bite him in the ass, and he was let go, but not before we lost a good customer, and I’d spent around five years complaining to the board about him.

How does the relate to the post office scandal? Having watched the documentary and the dramatisation, I see how both the project leads in the Post Office, and Fujitsu could easily have been overly defensive of their software/solution. Denying issues with their respective solutions likely earned them favour with their organisations’ boards. While minimising bugs is a commendable goal, it can morph into toxicity, contributing to software scandals. Neither side was willing to acknowledge potential flaws in Horizon, leading to profound suffering for end users in the post office scandal.

While keeping the number of bugs down to a minimum is seen as a good thing in the software world, it can become toxic, which I suspect in some way is part of the problem in software scandals. Neither side was willing to accept that there was an issue with Horizon. Ultimately, the end users are the ones who suffer; in the case of the post office scandal, their suffering was truly disgusting.

Whenever a suspected issue with the software emerged, the reluctance to investigate software issues was not acceptable. Even if suspicions about postmasters existed, probing the matter from a software perspective should have been a priority.

There is a misnomer in the software world that the number of bugs reported directly relates to the quality of the product.

I have never believed this; it’s more complex than that, but this idea still permeates the industry. It’s a nuanced issue. The key lies in addressing the types of bugs discovered and handling them transparently. Encouraging users to report issues without a defensive stance is paramount. Blaming users not only tarnishes a company’s reputation but also diminishes the trust in the software itself.

I wouldn’t usually write a professional blog on here, but it really chimed with me, the toxic individual involved in my last role, has a deep impact on me, the whole situation upset me, and added to my depression. It ate away at me day in day out.

Until next time, as I wave goodbye like a caffeinated octopus on rollerblades—until our next cosmic rendezvous in the whimsical land of Internet absurdity, toodles!