[SystemSafety] Post Office Horizon System

[Peter Bernard Ladkin]

On 2021-04-24 04:17 , Steve Tockey wrote:
> 
> I’m wondering why nobody seems to be considering holding the programmers who wrote 
> that code accountable. > Why aren’t those programmers sent to jail for equal time they caused the falsely
 > accused? Why don’t those programmers have to pay the reimbursements?

Because they are not the people who wrote the contracts which stated that 
subpostmasters were liable 
to make good any branch bookkeeping shortfall, no matter how that shortfall may have happened. And 
they are not the people who indulged in the abuse of process category 2 that sent people who jail 
and ruined the livelihood of others. In both cases that would be the company legal department, 
wouldn't it?

Had the subpostmaster contracts been different, and the company legal department not been as 
aggressive towards their contractors, this might well have been just another complex distributed 
system which took five to ten in-service years to debug.  Unsatisfactory UK government or 
government-backed large IT projects are not an unknown phenomenon in the UK. Trying to push all the 
failures onto the users, and succeeding (until late 2019), is, however, unprecedented.

> As long as programmers who write crap code like that are not held accountable 
> for their obvious failures, why would anybody even hope for anything to 
change 
> in how software is developed?

I don't think anybody knows at this stage that the code itself was unusually poor for such a system, 
or, if so, why. The system itself was apparently described in a report prepared by the system 
auditors Second Sight in 2013 as, in some cases "not fit for purpose". But the system was/is a lot 
more than the code. As Michael Jackson has pointed out, there are all sorts of HW and devices 
involved. Unless all those interfaces are well understood and monitored (and the traces recorded), 
there are all kinds of things that can go wrong that are not necessarily caused by poor programming.

For example, consider phantom transactions. How did those happen? People suspect touch screens that 
were physically not reliable, and recorded "touches" that never happened. 
To figure out that such 
things are possible, one needs close cooperation, and transparency, between hardware supplier and 
system architects, as well as knowledge of the HW product that may not yet exist, especially if it 
is new. How can you attribute any of that to programming? You need good post hoc error logging and 
traceability down to the fault. That is a company process, not a programming speciality.

Such a large system needs good technical oversight during development. Ensuring such oversight is a 
task for organisational theorists and auditing specialists, not for programmers.

Finally, before the system was deployed, in 1999, the government stopped the pilot project after 
£700m pounds had been spent on it. It is not as if everything went swimmingly until deployment. It 
is an issue of management and mismanagement of an exceptionally complex IT project. It is not a 
matter for the IT supplier and its employees/subcontractors alone.

> Leave the taxpayers out of it. They (we) are completely innocent. Hang those programmers—and their employer—out to dry. That will teach them. For once.

Many people involved feel that the supplier (ICL/Fujitsu) was not the main issue. The behaviour of 
the client, Post Office Limited, was much more at issue (see above). That 
entity went through many 
organisational iterations during the time frame of Horizon and, in its current iteration, has 
admitted it cannot shoulder the liability arising from the agreed compensation. So in that sense it 
has already "hung [itself] out to dry."

However, public-facing Post Offices and the services they offer are socially far too important for 
the daily life of millions of people in the UK for POL just to stop doing 
business. It doesn't just 
offer the public-facing services of post/parcel, but is also a channel for many social insurance 
transactions (benefits payments and so on) and other government transactions (e.g., road vehicle tax 
payment and receipt). It is too important to just stop all that, to fail.

There are various suggestions out there as to how to avoid such disasters. Where there are clear 
interfaces, log the transaction-data items which pass through the interfaces. This has been done 
with common Internet services since the beginning. Every mail server has a log of what has gone 
through it and the handshaking that transpired. It is a matter of a few minutes for a sysadmin to 
tell you what happened to your email. Stuff like that is a matter for system design, though, not 
programming per se. Another suggestion is strict liability for harm (including financial loss) 
resulting through use of such a SW system. Such a regime would surely have caused Horizon system 
development to cease in 1999, if not before. But Horizon sort of now works. Would the UK really have 
been better off without it for the last twenty years? Not necessarily. But certainly the country 
would have been a lot better off without the aggressive attempts to blame 
the users for all 
problems, as the court of appeal established yesterday.

I imagine there are books and books and books full of lessons to be learned over the 25-year history 
of this system. But they won't be written because of non-disclosure contracts and proprietary 
interests (including those of the state), as well as the personal interests of some formerly "key 
players". A public inquiry might manoeuvre around some of these hindrances, but will necessarily 
stop short of anything which might point towards malfeasance or culpable negligence of individuals, 
unless there is a general amnesty.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
ClaireTheWhiteRabbit RIP
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20210424/8fb8f3a7/attachment-0001.sig>