It seems to me that the Horizon system is just a simple accounting/POS thing. I can't understand how it could be built so shoddily. It doesn't even have that many clients: there are less than 12k post offices in the UK.
Here is an anecdote from a past job.
1. Years ago (decades), someone made the contract rules. They did it in an ad hoc not very systematic way. They assumed everything would be judged by a human and be judged reasonably.
2. That person left and the department expanded.The rules had to become more formalized, but still room for plenty of exceptions. An exception could be a penciled scribble in the margins in a file or later on, a sticky note.
3. Time to digitize. Unfortunately, computers like standards and need every little rule must be programmed.
4. A business analyst with no real understanding of the system is hired to generate requirements for digitization. The current overseer of the rules, someone who doesn’t use a computer much (yes, these people still exist) kind of just nods every time he creates these tremendous flow charts. this is the first degradation of knowledge. Even then though, this business analyst is not technical or legally trained, so doesn't appreciate why defining things like "end of day" or "contract billing cycle" precisely is crucial. even if he could, many contracts had sticky note individual definitions.
5. The business analyst goes back and feeds the information into the ticket mill of Scrum. To be nice and agile, work is done in bite sized increments with no regard for context. This is the second knowledge degradation. All those flow charts are chopped into little boxes. Devs see ambiguities, but have no interest in pushing back.
6. Developers only have the tickets to work on and quotas to meet, so write the code as requested. Testing is another set of people, so code is just tossed over to QA. QA has no more context than dev, so if it matches the ticket, they approve it.
6a. Nobody budgeted for automated testing so things break over time for lack of tests. Product Owner wouldn't grasp the concept, business analyst had a budget and wanted to deliver more features, and devs didn't want to fight about it.
7. Final increment goes back to product owner who doesn't understand and just nods. A piece of software that doesn't work all that well gets approved. Repeat for years and constantly adding post-it note rules as code and you have a system that has lots of errors.
A sane system would be 'contract A type' and all other be done manually or something.
Er....shit in. Shit out?
A great example of something hard to digitise is mechanisms for reward/punishment. Algorithmic approaches for criminal sentencing that work on a parameterised basis have been proposed over the years but always found wanting.
[1] https://www.theguardian.com/uk-news/2024/jan/09/how-the-post...
That said, it was certainly shoddy
'Shoddy', being a euphemism for 'beyond knowingly-being fucked-up, so much so that we'll cover it up oh fuck we're still alive this wasnt what we were told would happen'?
I dunno, or maybe just me surmising.
Yes, you're probably right. But this is the part that really bugs me :
"The inquiry heard that in 2008, a glitch in a system called CABSProcess, which automatically summarises a post office’s transactions at around 7pm daily, resulted in users working at the same time having balancing issues."
This, for an accounting system is just fucking inexcusable!
I worked on a huge accounting project for a financial institution processing 2M account bookings per day (at that time, it's a lot more now). A lot of effort was put into the audit log (every booking was written to an append only log) and into the reconciliation process. When it was 20 Rappen off there was digging until the inconsistency was found.
That transactions are not completely isolated when that CABSProcess kicked in is just completely and uttelry inexcusable.
<<I wish I was joking>>>
Not sure a sometimes offline distributed database where data is temp stored on POS machines is such an easy thing to write either
As usual: rushed, not well tested, assumed to be perfect