Eventually, the machine did spit out a ticket for the car park and returned the card. As it was not my car I compared the ticket with the registration number to ensure they were the same and placed the ticket on the dashboard facing the windscreen before locking the car and heading into the terminal building myself. We were just in time to board and once safely on the boat we could relax and settle up the payments.

We had a pleasant enough afternoon walking and sitting on the coast near Yarmouth and looking at the deep aquamarine water of the Solent along the island’s shore. It was beautiful weather. Only too soon it was time to go home and we took the boat back, collected my friend’s car and drove home. She nearly left the car park through the entrance instead of the exit but I pointed out if she did that the camera would not record our leaving and she would be fined for staying too long. She quickly changed direction and left correctly. I did not know at the time this would make no difference.

A fortnight later she got the letter telling her she had not paid for the parking and was being charged £100 for breaching the terms. She sent the parking company a copy of her bank statement and a letter from the ferry operator confirming the machines were not working properly and that the transaction on the bank statement appeared to be the parking fee. However, the parking company would not accept this even though the owner of the car park for whom they worked did. They continued to insist on the money she did not owe. My friend had to appeal to the ombudsman and I, as the person standing over the ticket machine while it ground away at a transaction which took around 15 minutes or so, supported her appeal with my witness statement. After giving my evidence of the events of the day I added “some technical comments in my occupational capacity as a computer programmer.”

“Programmers typically spend about one tenth of their time writing the initial code of the software, and around 90% of their time finding and removing errors which prevent the code functioning as intended. That is not enough to produce robust and reliable software, but will generally obtain basic functionality. To improve reliability far more extensive testing is required. There is no such thing as software which is 100% reliable, but with effort it is possible to reduce the error rate to an acceptable level. What constitutes an acceptable level depends on the cost of errors to the person paying for the software and the cost of rectifying those errors but, in most cases, would be the level at which those costs become around equal, so that it would cost more to improve the reliability of the software than would be saved by the reliability gained. Software errors can result in many different undesired results, ranging from crashes and vulnerability to attack, through loss or corruption of data, to minor irritations for the user. The less common the conditions in which errors occur, the harder and more expensive it is to identify them, or even prove that they are present. This means there is a high probability any software system will have errors which occur in unusual combinations of circumstances. However, if the software handles a large volume of transactions, those rare cases may arise more frequently, corresponding to the number of opportunities for the circumstances to arise.

“It is also likely that any software user will be unable to determine with any degree of certainty how frequently such errors might occur unless there is other evidence to prove the errors did occur in every case. In the absence of such evidence, any erroneous data would continue to be trusted as there would be no reason to question it. In the case of an accounting system for recording ticket sales, such evidence might be production of a ticket when there is no record of a sale, or the details on the ticket fail to match those recorded by the system. If such a case ever occurred it would call into question the veracity of the data, not just in that case, but potentially in all cases recorded on the same system, as the system would be proven to be capable of losing or changing data. However, if that never happened it would not prove the data stored was correct; only that no one had evidence of any errors, which might still exist undetected.

“The foregoing assumes a cost to the organisation paying for the programming if errors occur, generating an incentive to identify and correct the processes leading to them. However, such an incentive does not exist if there is no cost to the organisation, and a perverse counter-incentive would exist if the cost were replaced by a reward or gain. How much could an organisation reasonably be expected to invest in eradicating errors which brought it a benefit? So long as others (especially in tribunals and courts) did not realise such errors exist they could continue to benefit.

“That concludes my observations from a technical viewpoint.”

How apposite those comments look today in the light of the Horizon scandal! I repeat them here to show why we should never assume computer records are reliable, especially when the errors are to the advantage of the people paying for the software. Quite simply, turkeys don’t vote for Christmas; much less pay for it.

The adjudicator upheld my friend’s appeal, I suspect because she could show she had paid the original charge, and evidently thought the company was being petty and vexatious. Ostensibly, the appeal was upheld on a petty technicality in the wording of the claim, but as that wasn’t even in dispute and her summary of the evidence ended by saying the appellant had proved she had paid the original fee I have little doubt she was just being petty in return.