Developers Blamed For The Post Office Horizon Scandal?
ฝัง
- เผยแพร่เมื่อ 16 ม.ค. 2024
- What was the root cause of the Post Office scandal in the UK? Are the software developers who built the Horizon IT System to blame? And if not, at what point if any do software developers have a professional duty of care for the systems that they build?
Is it enough for Fujitsu who built the system to claim to be "sorry" while making billions in government contracts and producing software that couldn't achieve its basic goals of keeping the accounts?
Big Distributed software systems are genuinely complex things, we are always close to complexity and so prone to mistakes, but the commercials of software development often mean that projects like these are complex at the social and commercial level too. The Post Office Scandal has exposed all of these issues and innocent people have paid the cost over two decades.
At its roots though this was the result of technical failures of some software, so in this episode, software engineer, author and software thought leader, Dave Farley dissects the more technical parts of this story. Why and how did this software fail and what questions should we be asking? beyond questions about the reasons behind the scandalous blaming of innocent people for software failures that were known not to be their fault.
-
🖇 LINKS:
🔗 "Horizon System Overview" ➡️ www.fujitsu.com/downloads/SVC...
🔗 "Horizon System Audit Manual - Technical Outline ➡️ www.postofficehorizoninquiry....
🔗 "How the Post Office’s Horizon IT system failed" ➡️ inews.co.uk/news/how-post-off...
🔗 "ACID Transactions" ➡️ en.wikipedia.org/wiki/ACID
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! ➡️ bit.ly/ContinuousDeliveryPatreon
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#softwareengineer #developer #postoffice #horizon - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMSL SEA W2D5 | Summer | วันอาทิตย์ จะขิตหรือจะรอด!](http://i.ytimg.com/vi/-4JLNwQRK-Y/mqdefault.jpg)
I've worked in the government for almost a decade as a software developer, and I have seen some truly appalling systems that are not fit for purpose, developed by big consultancies. It's almost as if delivering a substandard solution is part of their business strategy.
You get what you pay for if government departments want to award contracts to the cheapest suppliers then you’ll get appalling software written by sub contractors in countries like India and the Philippines.
I’m a software developer for a U.K. based consultancy and our rates are much higher but so is the quality of our output.
"It's almost as if delivering a substandard solution is part of their business strategy." There are certainly different ways of interacting with the client. A profitable approach is do do what the client says without question. Then when the client sees that the result is not quite what they had in mind, charge them handsomely for the amendments. My approach is is always ask what problem they are trying to solve, and offer a solution or explain how that problem can be avoided. I know which approach is the winner...it's not mine :-)
@Asad-K It's not just government, I work for a large corp in the private sector and its the same story, some exec with no clue decides to try save on IT budget, offshore all dev work, all projects have major defects or run over time.
I've always seen the problem that non-technical people are deciding who to hire. They look at all the wrong factors (cost, the promises made, the slickness of the presenation, etc).
@@Asad-KHaving known some people directly involved in government contracts as well as being the unfortunate 'customer' of one particular government system I can say that low cost and value for money is pretty much never an objective.
What usually happens is they will pick their preferred vendor in advance, often by tailoring their requirements so they exactly fit one particular company's existing offering, and then make it as difficult as possible for competing companies to compete.
Things like only allowing 28 days to submit an offer, but you won't get to see anyone regarding further details until 14 days past the tender being put out or issuing tenders through a third party, usually a consultant and blindly going with whatever their recommendation is. My brother was once involved with a case of the latter and the ultimate client knew full well they were paying around 7x the open market rate. But if anything goes wrong it's the consultant's fault and if they don't spend the money then their budget will be less next year.
It's often similar in business although savings are usually made and kept by the consultants. I remember one system, which had obvious defects such as bizzare memory limitations, regular crashes and the ability for users to easily put the database into an inconsistent state. Very expensive project, British contractor with Indian developers but the orders from the director were 'It works, and don' t say otherwise'.
The developers fucked up the software, but there were internal reports by developers to the management at Fujitsu and the Post Office that detailed issues with the system. These reports were ignored and buried. Not only that, they were illegally hidden from discovery in trials.
The developer has some duty of care, but when the issue is reported and the report is buried, they have largely absolved themselves of that duty because the burden of responsibility is now shifted to the management who actually has the power to take action.
Yes indeed, as made clear in the closing statements at the end on Phase 4 of the Horizon Inquiry.
Software developers are the easy scapegoat. However senior management at the vendor and Post Office should also share in the blame. How can they not have tested this? Surely failed networking is a requirement. Then you have the failures to own the issue and respond honestly and appropriately. So product and software development did a poor job but the reasons lives were taken and ruined is because organisations didn't act with professionalism once errors were found. It's absolutely disgusting this has gone on for so long. Poor leadership is the root cause sadly.
I mean this went on for years, there's plenty of blame everywhere to go around including Fujitsu.
The trial roll of Horizon showed some of the difficulties and the feedback included concern for the mental health of the participants. There were even warnings that unless the system was improved there might be a tragedy. So the head of the Horizon project for the Post Office took all that in and went back to the board to tell them everything was great and Horizon should be rolled out.
He got the job without any kind of interview or even relevant technical background and still thought when he was at the inquiry he hadn't don't anything wrong. So yeah, that's one person who could have fixed everything but the board could have insisted on a more qualified person for the job. Fujitsu could have looked at how their software was working and gone "hold up we've found some problems during the test we need to address".
And as an aside Fujitsu was told internally there were problems. They were told by an internal audit that the program was so incompetently coded that it looked like it had been written by someone who didn't understand basic math and that they would start from scratch. They had a help line full of resentful experts who would demean and insult callers with issues.
So definitely there were structural issues at play and a lack of meaningful conversation with dozens of people who had the information to stop this scandal years ago. But Fujitsu has been aware of the problems right from the start and have been happy that as long as they had a good reputation that could get billions in contracts from the government.
Like blaming pilots for aircraft that crash due to poor maintenance or organisational processes.
Actually the pilots of the first Boeing 737 MAX aircraft that crashed were blamed for it.
When the second one crashed, the initial reaction was the same.
You know, those pilots from overseas or developing countries, they can't be any good, cant't they?
It can even be noticed in other replies to this video: the general belief is that programmer's in other countries are substandard, so when outsourcing to abroad you get substandard quality.
Quite racist, of course. And in the end the programmers can't be blamed at all, the full blame is on the management. Especially for not noticing that the same pattern repeats time after time and results in 980 prosecutions.
They did test it , ( to an extent ) that’s partially how Fujitsu populated it’s known bugs database very likely with many thousands of bugs , some small some huge . Not to say all bugs were transaction sensitive , but some clearly were .
I was once a Subject Matter Expert testing a ERP system that had been ‘tailored’ to my employers particular needs ( not a good idea)
I populated ‘known bugs/ error’ spreadsheets , and helped prioritise those bugs that I thought would effect my particular function ( Other SMEs were doing the same thing )
A further complication was my employer had it’s own I.T staff and various other systems that had to populate from or integrate/interrogate into the ‘New ‘ platform .
Throw then into the mix , then developer’s management , my employer’s management , and the SMEs had a poison chalice , as they were under pressure to accept a system that was not just not ‘ bug’ free , but riddled with them , and if the SME signed it off, they themselves were the ones that would have to use it back at their own jobs , and teach their colleagues as well, so it was a case of do you want to be shafted pre going live , or after going live .
I have the greatest of sympathy for all the SPM users who’s suffering is literally criminal in many cases , but I also understand , a little , of what might have been going on behind the scenes at Fujitsu , and the blame , in my experience , will lie with management of both Fujitsu and PO who were playing office politics , and ultimately playing with SPM’s financial and mental health as well as their freedom .
There ARE serious criminals in this story , but I’m not going to be looking in sub post offices to find them .
@@A2Z1Two3 Somebody has to have signed off on the Horizon system to indicate that it was accepted by the Post Office for commercial launch. The individual or individuals within the Post Office who signed that acceptance need to explain why they signed that acceptance certificate and what agreed / contractual obligations they adhered to in accepting Horizon (in particular Quality Assurance measures to be followed under the terms of the contract with Fujitsu). As Fujitsu will more than likely have had a payment milestone related to Final Acceptance of the Horizon system, the entire contract of supply for the Horizon system needs to be reviewed. Clearly, adequate testing of Horizon did not happen as defects arose in Horizon in production / commercial use. The cover up of the defects in Horizon would not have been needed and the Sub-Postmasters lives would not have been destroyed had the Horizon system not been commercially launched with critical defects. As there is now testimony from Fujitsu witnesses that it was known there were defects when Horizon was accepted and put in to commercial use, the first cover up must be related to the decision to accept the Horizon system knowing it was defective. Who in the Post Office authorised the commercial use of Horizon? Who in the Post Office authorised payments to Fujitsu for the Horizon system? Who in the Post Office provided oversight of the contract of supply with Fujitsu? To me it looks very likely that a decision was taken to launch Horizon before it was ready. The select committee need to identify that/those reason/reasons.
The behaviour of Fujitsu is shocking. And as they could have predicted, this has now come out, and will cost them in the order of a billion pounds in damages.
I never understand how some people will protect their own image & ego in the short term, while ensuring its destruction in the long term. The managers that made the choice to keep this bug under the rug may well face criminal prosecution.
They should face criminal prosecution, but they probably won't. Even when they were found in the wrong, the consequence was extremely minor and they all kept their executive positions.
"I never understand how some people will protect their own image & ego in the short term, while ensuring its destruction in the long term."
It may be hard to understand but it is common enough in business and (particularly) in politics. Short termism is known to be costly. The most successful companies invest for the long term. Having worked for both, I can attest to this being the reason German companies are broadly more successful than British ones (in manufacturing industry, anyway).
As far as I understand from the news, their contract exempts them from any liability. I wonder if that will hold up in court.
@@RolandHesz I don't think any contract can exempt a person or company from criminal law.
Correction, it will cost the business a billion, not the managers that did this bad behavior.
The biggest scandal here is that judges actually ruled against people on so many cases! Surely there jurisprudence on these cases and as a DA you would have a thorough investigation into the plaintiffs! You know that the post office and their manufactures will hide from a clusterfuck. Also me as a post office employee would immediately blow the whistle when after a new system accounting irregularities popped up on a massive scale; especially with franchisees who have had no inaccuracies every before!
The legal system works differently in the UK and the Post Office ran their own parallel legal system within the company and franchises.
@@spankeyfish but a judge or at least a defense lawyer would’ve looked at previous outcomes of similar trials and the name of the plaintiff must have come up several times, causing alarm bells to go off. Right?
@@CallousCoder No
@@incandescentwithrage What no! It shows how incredibly bad the legal system is and that judges do not do their jobs properly and the DA do not do their jobs properly otherwise you would've found so many identical cases that you it should've raised red flags. Especially when they are responsible for what happened to these people because they made sure they were convicted and ruined -- obviously innocently convicted.
If I was the judge I would've not convicted anybody until I had an independent software engineer and the digital investigation team look into every aspect of the code. Because it's more likely something is wrong there (especially after an introduction with a new system) than that a person is suddenly a criminal who already worked as franchise for 20 years. It is a simple case of Ockham's razor! SOFTWARE FAILS ALL THE FUCKING TIME! :D
I'm no expert, but the CrimeBodge YT channel recommends against getting a public defender as it's in their interest to make their client pleade guilty , to get repeat business from the court .
I blame the entire system, from programmers to higher management and costumers, because there is a dangerous generalized trend of putting code out the door instead of focusing on quality code. I sometimes clash with other programmers/managers because I prefer to work slower and put out quality work, covering all potential bugs as much as I can.
I always treat my code as if it could kill someone, even if it is the most simple of programs, because I know that inevitably someone will use that code on something it was not designed for.
I understand that there are financial considerations and that is why I always mention in the job interview that, if a manager wants me just to write code as fast as possible, I am not the guy and they should consider someone else. I prefer to keep looking for a job than to be a part o something that might cause trouble down the line, both for the costumer/users or me (because I might be liable/escape goat for the bad program).
When questioned about why I work like that, I often just reply "A program that works most of the time, does not work when you really need it".
You say "of putting code out the door instead of focusing on quality code." but the evidence, over many decades, is that very few customers, individuals, organisations small, large and huge, actually want "quality" code. They invariably prefer good-enough code, now, and at a low price. MS-Windows is a classic example and one of the many reasons it won over OS/2, for example.
@@edwardkenworthy7013 That is one of the reasons why I said that. Most of the times, the various people involved in the process settle with whatever "mostly works now". Underachieving has become the norm.
One of the problems is precisely that the qualified people (software companies/programmers/managers/etc) have early on indulged the unqualified (consumers) in the "this one is cheaper", even if that brings big problems for the future. That is why we get so many low grade products, and I do not mean just in software. Some will even kill you in the long term. Remember asbestos/mercury/CFCs? They were all cheaper options at some point.
Technical debt will catch us all eventually, if it hasn't already started, and maybe then everyone realizes that choosing the cheaper option now is more expensive, in more ways than one, than trying to get it as close to perfect as possible on the first try.
I do not know the solution for this, maybe education of everyone including costumers? It is a problem bigger than me, but any solution will only work if everyone works together to achieve it. I try to do my part by refusing to lower quality at my personal cost.
@@edwardkenworthy7013 I'd hope you mean "good-enough" but written with 100% QA built in? If yes, I'd suggest that is what the OP meant i.e. cover the URS perfectly with perfect QA guaranteed. As the OP said, focus should be on 'covering all potential bugs as much as you can'. That is a huge part of assuring quality.
If, on the other hand, you mean pushing out code that has not been fully QA'd then those companies that do this should be damned, though.....
Quick question (I'm nor a pro coder): Is QA here a standardised/regulated action? If not then there lies the root cause.
@@ChrisM541 No, I meant exactly what I said. Good enough. Probably has bugs, missing functionality, rough edges and doesn't meet today's needs because the requirements (and price and delivery date) were fixed years ago during bidding, when very little was known about the system (because it didn't exist!)
You need to take a risk assessment. If you're building nuclear power or air traffic control, then postponing and doing it right is the only way, if you're building an order form for pizza, then you can probably do without a lot of the corner cases, and you can get revenue weeks earlier. So it depends.
In my 30 years of building these systems, it's very rarely a technical issue (in fact the technical aspects are almost immaterial) ....
it's much more of a management/business problem ... As you say Dave, these systems are organically complex and if anyine loses sight of this, failures can happen.
Failures do happen of course. The main failure is ministers and MPs not listening and not acting on feedback.
But this is 100% developers fault also. Anyone with more than 6 months of experience should know to that money management must be wrapped in transaction. That button should be disabled while transaction is running...
I think it is the Post Office and Fujitsu more to blame, they decided to hide the issues from everyone, ministers have large portfolios often outside their expertise and rely on civil servants incl from the post office and ministers are reshuffled to other roles after only a short time. For example I heard it reported that Norman Lamb was only minister for 6 months but met the sub-postmasters alliance look concerned and was starting to investigate when he was then moved and replaced by Jo Swinson who then instead believed what the post office told her. The real issue is the desire to hide the problems. Developers of course also have responsibility but management at the Post Office and Fujitsu are the ones who both poorly managed the development and then chose to cover things up to save face.
@@ivanjezakonful True enough but management knew the issues and failed to act. Effective software maintenance relies on bug reporting and bug fixes.
@@ivanjezakonful Anyone knows that, but in very complex system it might not be obvious that it is transaction but in fact it isn't or it isn't isolated correctly or many other potential problems. In reasonably managed team there must be robust testing procedures to ensure that even if someone made a mistake it doesn't reach the production. And if some issue reaches the production impact of it should be minimized. Hiding it and prosecuting employees isn't minimization of impact...
I've been dressed down a number of times by senior management after identifying bugs as an issue, in IBM and Microsoft Software.
Each time, management made it clear that I was just making excuses for my own failures, because IBM and Microsoft were incapable of releasing bugs in their software.
One particular instance that I was demoted, and given a pay cut for, was when I released an application built with a newer version of the Microsoft C compiler, than the compiler that had been used previously. It was the compiler provided to me by management.
The bug that occurred, that I took heat for, was that the timestamps of all of the records in our code were dramatically changed.
I was able to determine the cause of the problem and demonstrate the bug before Microsoft owned up to it.
Microsoft did release a bug report for this, and fixed the bug in the next version. The bug was caused by the time function using a different base number for 1970, in that release.
Still, the damage was done to my reputation at that company, I soon found another job that paid better, and had better benefits
I would never work for a company where a bug would result in a pay cut. Never. Glad you got out, so maybe they did you favor ;)
@@Axel_AndersenYeah, it is a symptom a dysfunctional workplace, and narcissistic managers.
The idea that large companies don't publish bugs would honestly be so funny if it didn't impact folks like this. Glad you got out of there
Same , a bug in DotNet stopped me from completing a task, except the bug was acknowledged by MS, who marked it as cannot fix for backward compatibility reasons, management unsurprisingly did not care.
Which compiler was provided by management; the newer version or the one previously used?
Seen it firsthand in consultancy, some people don't care past getting through the day. Raising issues might get silenced by leadership or folks just get angry they can't just do happy path development. Sometimes this is simply decided by the client, against all recommendations, often with no traceability.
This is one of the most brilliant pieces of analysis that I've seen since the Post Office scandal finally worked its way into the British psyche. You really got to the root of the problem. I'm really impressed with how you clearly articulated the problems inherent in designing software architectures for Banking and Distributed Systems and how badly software is often written. Even I managed to understand it. 🙂. One thing that I hope will result from this terrible episode in British justice will be for people to no longer just assume that "the computer is always right!" Excellent video! Thank you!!
Thanks, I am pleased that you found it helpful.
It's hiding a fundamental problem at Fujitsu to claim the system is "complicated". For example, where a subpostmaster entered a value and realised that value was incorrect ( £1300 entered instead of £1500 say), the subpostmaster could _reverse_ the original entry and then enter the correct value. But Fujitsu's code instead of _subtracting_ ("reversing") the amount _added_ it back on! Two minutes testing by the developer crafting the code would have shown the error. The testing team (if there was one!) could have seen this in short order. Any regression testing (if such was done) should have flagged this. But no! It took a subpostmaster to notify the PO who then notified Fujitsu. There is no "complicated" here, this is Software Development 101, Testing 101 and it seems as if the whole development process was severely lackadaisical and simply not fit for purpose. Yet Rishi Sunak continued to dole out £billions to Fujitsu. It beggars belief really.
It also looked to me from the answers at the inquiry like software changes were not being documented properly - unless they did document it but were not willing to share the data, of course.
Testing team? Regression testing? What are these strange concepts of which you speak?
In other engineering fields, when the final product is turned over to the buyer or governing body , it's turned in signed by certified people, who are liable in court if what they signed turned out to not be according to standards and specifications.
So I would say that what you should have is a regulatory body that will accept and check these products according to standards ( i guess a body for making them also). Self regulating will never be enough.
"Self regulating will never be enough."
Absolutely. Boeing is a prime example.
IT is certainly less mature than engineering in following quality processes. Still typically, large projects do follow a formal process - requirements, architecture design, build and various stages of testing. There should be traceability through this process, though it is not always strictly followed. The customer is expected to sign off each stage, based on reports from the supplier. The supplier and customer should agree acceptance criteria prior to testing - e.g. no severity 1 or 2 bugs, some 3 and 4s. Having a regulatory body review things would be expensive. The rigour of testing tends to be related to the criticality of the application - e.g. a fly by wire aeroplane system or a system for handling international money transfer between banks would go through an extremely rigorous process.
Institutional obstinacy. The issue is not the bug but how it was handled and how the post office treated the postmasters.
At the end of the day it's all about incentives. You get what you reward. If keeping technical debt under control and having high levels of test automation are rewarded that is what you will get. If you reward shipping features as fast as possible without regard to maintainability and reliability that is what you will get. Generally non-technical project managers will prioritise doing things quickly over doing things properly. They should not be allowed to rule the roost. Engineers should be able to push back. Perhaps litigation is the only way to ensure quality. If the software fails dramatically the firm who created the software should be liable. That would incentivise quality.
That point about engineers and managers was a focal point in a Netflix documentary about Boeing.
"fail" is such a loaded word. It can be defined and redefined ad absurdium. Contracts have to be developed by competent deployers and you're not going to get that from a government agency because they have no incentive for competency tests for hiring. Contracts need to be specific to what's needed so that contractors can be held responsible.
@@angelmarauder5647 That's not a government issue. Private business clients do exactly the same. Purchase teams everywhere are incentivized to spend as low as possible on the short term, grab their bonus and move to another position before the sh*t hits the fan. The actual problem is short term individualistic view. Humans are just resources. Why would they care for the grinding machine that is shredding them?
Push back often ends with retaliation. I've experienced this firsthand several times, even as a contracted developer raising issues with commits not being peer reviewed or tested. Or test stacks, insecure APIs password and all, being rolled out as production because the intended production stack wasn't ready. One place, I was so annoyed by being ridiculed and ignored, that I cancelled my contract at my cost. The issue went all the way to the top there.
@@conceptrat It does, but too much retaliation causes engineers to resign, which also kills projects
Handling of the bug reports is the shocking thing for me. Who hid the bugs are truly culpable.
Open BTS would have really helped imo. Postmasters would have quickly discovered they are not alone!
I believe it a massive collusion between all parties. I don't know how you could have gotten to this point in time considering all parties involved and the time that has past with all actions taken into account. This is massive. MASSIVE
You have to remember the era. When Horizon was rolled out there were users who had been doing all their books with paper and pencil to this point. They had little to no computer literacy, the training they recieved wasn't sufficient and they were all told if they called for help that they were the only ones having problems with the software.
This was also before the era of ubiquitous social media. People genuinely did not know what was happening. They thought someone on staff must be responsible or that they had made a mistake or the cause was something else. Like there was one union member who's niche speciality was in finding hardware explanations people could use to explain why their books weren't balancing. Like he found a computer that wasn't working because it has been got at by mice. It wasn't until after the scandal started to get some media coverage that the victims found out what had happened. Dozens of people had gone to prison without any hint that it was Horizon to blame. It wasn't until they saw a article or where shown an article they started to understand what was going on. Even now there are still new people are entering the compensation schemes. That includes people who have just now found out what happened to them which is years after the issues with Horizon were proved.
I had a manager who thought that distributed consensus was obvious and easy (circa 1991). I had this cool little MIT Press book called, “Algorithms for Mutual Exclusion,” and I quickly realized that none of that was true. Good luck convincing that manager though.
I did the usual thing when faced with incompetent management. I quit. :D
Later I worked for Fujitsu in San Jose. Ugh. That’s my only comment…
"I did the usual thing when faced with incompetent management. I quit. :D"
I once overheard a management conversation: "Software people are great guys but the main problem is keeping them.". I think that if management made the most perfunctory attempt to understand what they are being told by software guys and acting on it then they might keep a few more of them. I once overheard a conversation about myself: "We've only got one guy who understands that (key) system and he rocks up every day on a motorcycle and shoots antique firearms as a hobby.". I could have added "and he is never listened to.". I don't work there any more...
Thanks for the clearest explanation of the technical issues that I've seen anywhere. In particular, this is the first I've heard of the size and capabilities of the software team. My perspective is as someone who helped build an SMS-based mobile money transfer system used by millions of people in which the core development team was 5 people so I know that it is possible to build something like this with a small team although this was in 2005. Keeping the electronic view of money transfer in sync with real-world cash movement is a tricky problem that requires careful end-to-end system design, including usability. ACID transactions only go so far - you can't enrol a customer in a transaction and make them rollback if they already left the Post Office. One of the things that I learned is that most software developers don't understand the issues inherent in such a mission-critical, highly scalable and highly reliable system until they have at least one under their belt. Most software developers come from a background in smaller systems in which errors are an exception and error handling is often an afterthought. For these critical systems, coding for errors is the norm and a desirable, non-error situation has to be considered the exception.
A 'duty of care' would be a great way forward for our industry, along with legal ramifications for 'boards of directors' who prosecute people for things they know are false. I also love the quote on Dave's T-shirt of 'The measure of intelligence is the ability to change' a great video all round.
I would like to say, as a professional software developer of 30 years, these are cultural problems.
Quality is built-in actively; it cannot be tested in. This requires an engineering mindset aware of potential for issues, acknowledgement of possibility of issues and tracking / correcting issues as they arise - as part of the software development process. Effort and time is necessary.
The cultural issue comes where management do not accept this, being either self-important / self-inflated (we can do no wrong, as we're the good guys!) - often resistant to communicating problems vertically to top management - OR totally untrained, often just an MBA brought up on accounting, marketing and spreadsheets of budgets.
Short / impossible deadlines do not help, indeed I am aware of an impossible task given to a small team. Two guys delivered a wonderful fantasy (which ticked all the contractual boxes) simply as a response to deliver an 18 month project in 12 weeks, which is all management allowed. I wonder how much financing was responsible for this; the lowest bid won but the output should have been hung up in toilets for wiping purposes. NB this was a complex report and nothing to do with software or the PO issue.
This is exactly the approach that has been an essential part in companies building extremely safe stuff. Only the top management has enough authority to require that safety always comes first. Fumble this step and don't be surprised that things fail dangerously.
Ps. Nothing lasts forever. One company building extremely safe stuff was Boeing. Then they dismantled all the important functions and basic principles within the company...
As soon as this blew up over the last few days I was reminded of the classic book, "The Case of the Killer Robot" by Richard Epstein in 1976. It is about a robot that goes wild and kills a person. Who was to blame? The programmers? The CEO's? The managers? The developers' company? Client? The book explores the ethical issues raised. This book should be compulsory reading by all involved in the enquiry. It is used in university courses on ethics in software engineering.
In the case of Tesla and similar, the answer seems to be "the dude sitting behind the wheel not paying attention because all the promotional material said 'self-driving'".
@@traveller23e It's not self-driving. It's self-driving*.
*Driver must keep hands on the wheel and be prepared to assume control at any moment, Tesla assumes no liability for driver error in following these instructions, Tesla self-driving is a driver-assist feature and cannot self-drive.
I am a developer who used to work at the post office in McColls, the software was horrible and you didn’t get really much training
The one thing that caught my attention is the corrections that could be made with no audit trail - as if the sub-postmaster themself had done it. That in a production system is farcical.
Sorry I was trying to follow along with the detail discussion on the Inquiry TH-cam videos (but I also have a life soooo... may have this wrong), from what I was hearing it sounds like corrections did leave an audit trail, something like they added 10 to a counter number so they could identify this action was being performed remotely, but it was also pointed out this addition of 10 had a weakness in that some larger branches would have more than ten counters. However, the bigger issue seems to be that these corrections were made on a different month to the requested records being used to identify fraud. It seems that the books didn't balance in May so the corrections were made in June and so when it comes to identifying fraud occurring in May the process was to inspect the Audit Trail ... well for May.
Hence we have bugs, being solved by additional corrective processes, and those processes in themselves introducing issues into other processes. It's not only software having bugs it's the case of processes to either fix the historical data introduced by the bug, or cope while the bug is being patched, and because these fix processes by their very nature are not part of the normal functioning of the software and the wider systems and processes, they themselves have issues and bugs in them. If when we make fixes to bugs and implement migration software to fix issues introduced by the bug we often ensure we're testing we've fixed that specific bug ... it's a lot harder to understand and test wider issues that may appear on reports or have already slipped into manual processes of offline spreadsheets.
Fascinating. I was a CPA/CBA, bank auditor in the US for over 30 years, the last 7 before retirement in IT auditing. The core of this unique problem was as pointed out, the amoral collusion between PO management and the vendor.
The enquiry needs to get a hold of the implementation, full testing and audit records, who signed off? I've worked on projects where i managed the user acceptance and regression testing. The crap i copped from Project managers was incredible. The cio et al were paranoid about kpis and performance pay. Telling the board all was in track. Systems signed off as the modules worked, a full test? I refused to sign off until full runs were done. A wages system i worked failed at final pay run an no bank transfers would have a worked. Ten thousand wages employees would not have been paid. I looked around table and said I may have saved OUR jobs. Silence!.
8 software engineers working on this? Seriously? How much did I the taxpayer shell out for this to be built?
Hundreds of millions...
The Netherlands had a similar scandal only with childcare benefits, only at an even larger scale with even more severe repercussions for the affected families. People financially ruined, children taken away to the point for so long that even now they're (slowly) being made whole again their children are estranged and no longer want to return.
But that wasn't a software problem in the sense that it would misappropriate money.
It was a system that determines fraud risk by looking at parameters that are often associated with fraud.
When the outcome was "fraud is likely", PEOPLE would (similar to what happened here) act as if there indeed is fraud.
And when that happened very often, they would not notice that is peculiar, they would just go on and prosecute more and more people.
The software itself wasn't really faulty, it just was used in an irresponsible way.
While software developers have a professional duty to do their best, I feel the main responsibility lies with their principal. This team did not have the skills & knowledge to build this system. Otherwise it would have instituted processes, tests and mechanisms to ensure ACID behaviour. But I don't think you can blame people for something they did not know. The final responsibility is with the principal who trusted them, not the developers. Fujitsu is not a small company and has a LOT of experience with critical systems.
In a normal situation, in a healthy company, the pattern of faulty transactions would have been picked up quite quickly, remedied and its victims compensated. There must have been logs from which the behaviour of the system could have been reconstructed, and the culprit identified. The Post Office didn't do its due dilligence in find the root cause of the problem, but instead assumed the office managers were at fault. Without proof.
And it is a dire indictment against the UK legal system, that they followed the Post Office in its findings, without demanding proper proof that the SW system was not at fault. Courts must be aware that SW can be at fault.
Very true - the legal system in the UK is an archaic mess. it starts with an collection of investigative agencies which lack anywhere near the levels of technical or scientific competence required for any crime above petty theft or anti-social behaviour, and even then ... they struggle.
Subtle semantic distinction, but as I understand it the software will not be at fault (responsible) until it achieves consciousness, merely faulty (containing a defect). It is reckless, biased and illogical development, deployment and particularly defense of the software that deserves blame. To no small degree, I suspect, the result of the software industry's standard of accepting absolutely no responsibility.
@@0LoneTech "accepting absolutely no responsibility"
The software industry is perfectly willing to accept responsibility -- except that almost no-one is willing to pay us sufficiently for us to take responsibility. So, in order to save money, we are forced to cut corners.
Writing software is the most complex activity humanity is capable of. We can do a lot for a price that is acceptable. But the costs for doing a perfect job are tenfold (if not more) of doing a "mostly OK" job. Ask the medical and military industries.
@@TheEvertw Did you know it's possible to have sliding scales? I described the standard set by the legalese tripe that is EULAs, TOS and such, not the limit of possibility. Feel free to point out any piece of end user software that surpasses that standard, perhaps to as high a level as the book The Art of Computer Programming, which carries rewards for finding bugs.
@@retiredbore378 Thanks for the insult, dude. I'm an MSc (EE) with 30 years experience developing firmware.
I have worked for software companies in QA developing for the public sector and Ive seen completely incompetent client representatives that overrule technical expertise resulting in substandard solutions.
People have an idea that anything is possible on tiny budgets and are unwilling to compromise on scope. Ive seen one system where the clients force of will meant that the system looked like a cowboy job because the budgetary constraints and the scope and the clients ignorance necessitated hacking their way through it. At one point they insisted that it was ok for us to record the wrong information about employees payroll, to which I said "we wont be doing that unless you put in writing that you are requesting the deliberate non compliance with data protection laws.
I think the last part of your comment is the part that I am trying to talk to. Clearly you did the right thing here, and of course there are often commercial, and other types of pressure that are applied to people in all sorts of jobs. I think that ultimately it is for each individual to stand up, as you did in your example, and say "no" to things that aren't right. Software development as a career would be in a better place if it were clearer that this is part of our responsibility, and if we provided training and better guidance on what "good" looks like so that we would, as a profession, be in a stronger position to defend people when they were forced into the position of having to be brave and say "no". There will always be risks when you make that choice, last time I did it, I assumed I would be fired, I wasn't, but I didn't know that when I said "no" I just knew that saying "no" was what I thought the right thing to do!
Well done!
Unfortunately sometimes these company offer these contracts to the cheapest developers, some government systems are truly horrific too and are probably on the verge of collapse similar to this.
So many people to blame with this entire thing. So many people knew what was wrong and let it continue. I still don't understand how the judge or judges sent these people to prison despite knowing there were hundreds of other cases. It's baffling.
Judges apply the law, period. The baffling thing is the postoffice and ministers doing nothing.
@@Fred-yq3fs and especially the post office prosecutors who must have known early on that something was badly wrong but carried on prosecuting anyway
Application of simple statistics could have prevented all this. No one with power seems to have asked "Why is there such an increase in fraud cases among our sub-postmasters?".
@@TheRealWindlePoons That was my point. More than 3 or 4 cases should have raised a red flag. ..hundreds of cases would have made it pretty damn obvious.
@@steves9250 It's a matter of perverse incentives. Prosecutor's job isn't to see justice done, it's to get a conviction. If they fail at that, they've failed at their job, and it takes a real spine of steel to do so willingly, especially when you merely suspect but don't know for certain that the defendant is blameless. The problem lies in the very heart of an adversarial justice system.
This is not a new problem, either. In the biblical myths Satan was originally described as an overeager heavenly prosecutor before becoming the wholly evil Devil of Christianity who is still kinda doing a perverted version of the job, trying to get people to be convicted (damned). Regardless of the metaphysical status of that myth, the process itself is basically what happened here, and keeps on happening as long as the job is "get conviction" rather than "do justice".
In short, a system designed to put people into the role of the Devil achieved results that would make him proud. What else would you expect?
Having seen the television series and many TH-cam videos on the Post Office disaster this is the first video I have seen that explains the technical structure in a way that anyone could understand especially the current investigators who are not necessarily technically minded. I have developed software in my past that interfaced with the banking systems and as you have explained it is a technical structure. Thank you for your clear explanation
👍
After 30+ years of working as a software developer in various companies, including our government and MOD I've seen plenty of terrible systems, poorly designed systems, poorly tested systems, systems released before completion, and systems that were not fit for purpose. People at the top love to play the blame game, but it's not always that simple. Bugs in code can cause nightmare problems, but are mostly found during testing stages of which there are usually numerous levels. A bad design in the first place ends up coded in and can then be hard to track as the code matches the design.
Nobody at the top wants to take responsibility, so it turns into a bit of a witch hunt to find the scapegoat that everything can be blamed on.
15:23 "2 out of 8 good" Here's my version of this scenario. I was on a financial project years ago. There was a genuine shortage of people with experience of the computer language. But not to worry, another country could supply 6 people with 2 years experience. We took them....2 were good, 2 were ok, 2 struggled. One of those who struggled let slip that none had 2 years experience. They instead were sent on a 2 week training course, sent half way round the world and told to keep their mouths shut. What happened? Not quite what I expected. They were all kept on, the two who struggled moving to the test team (not to denigrate testing, its a skill in itself). What did I learn from this? Suppliers of staff are willing to lie about those they supply. Users of those staff will turn a blind eye so long as they are cheap and a profit can be made by charging them out to the client. If I were the boss, a better approach would have been to hire 6 trainees from the local economy. I'd expect a similar result. 2 good, 2 ok, 2 struggle. But at least you're supporting the native workforce.
"native workforce"? Yeah.. cause people are different, right? We are all a bunch of skeleton bags walking about. Don't fool yourself with your savior complex trying to argue that by supporting "native workforce" you would be excused for achieving the same bad result.
You're trading 6 for half a dozen. All the same.
If you want to support the local economy, go shop at your local food supply chain instead of Walmart or Amazon.
@@DimitriMoreira "achieving the same bad result."? A foreign agency supplied 6 people who were meant to have 2 years experience. That was a lie, they'd been a a 2 week training course. In terms of productivity, it wasn't a bad result. Only 2 from the 6 could not perform and they were reassigned to roles better suited to them. Those 6 were probably sharing accommodation arranged by their agency and being overcharged for it. They were exploited. Yes, I would rather have hired 6 natives and sent them on a 2 week training course. If there's a skill shortage, take on trainees.
"cause people are different, right" yes, and cultures are different. I've been on very cosmopolitan teams. It was fascinating to observe how people from different cultures interact with management/authority.
The first behavior one must address in networks is that they don't. Network failure is a normal condition. It this surprises a system then the system is prima facia at fault.
Yes, they have some blame, but not that much.
The largest responsibility for this f-up goes to the Post Office and the legislation that didn't do their work (or did they....?). *They* argued to fine the franchisees, to put them in jail, making their lives miserable.
This, all day. All of this hurt could've been avoided had the Post Office acknowledged the issue and not then undermined and prosecuted their own staff. You can't blame poor development for the deaths and lives ruined.
If the senior devs were saying that only 4 were capable of building the system, and in turn, blaming bugs or substandard code on the lesser skilled other 4 devs, why are they then not taking reasonability for the quality of code and capturing / reviewing poor quality commits? How much testing was done? There's definitely more questions to be answered there.
Also, only having a team of 8 sounds incredibly small for a system of this size and importance?
Agree a chunk of blame but not all
@@deldia Such blame isn't shared like a Christmas pudding. It's a lump of crud in a fan, thrown in all directions. If the coding hadn't permitted correcting entries designed on the fly without full and complete double-entry posting, the rest couldn't have happened. What followed is a multiplier, so you may get a total culpability far beyond the simple events. There are serious lessons to be learned here, far beyond just this failure, and denial simply says you shouldn't be let loose on anything more serious than toy games.
@@JelMain yeah but Jenkins probably mislead too.
@@deldia Yeah but the trains ran on time. It's the classic covered-up denial, and it doesn't wash. Denial of responsibility, distraction. And at that point, it all goes south. Like I said, the crud-storm is in all directions. Once the poor widgets had been set up, it gave an opportunity for the Security Sadists to unleash the dogs.
Some professional societies (e.g., IEEE ) have a code of ethics that requires members to refuse work for which they are not competent to deliver with competence and professionalism. The clause reads: "to maintain and improve our technical competence and to undertake technological tasks for others _only_ _if_ _qualified_ _by_ _training_ _or_ _experience_ , or after full disclosure of pertinent limitations;" Another clause that would have helped prevent this kind of debacle reads in part: "to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors..." Not that having a code of ethics will change very much when professional engineers (and/or their management) lack a moral compass.
the IEEE is also a worker visa proponent, they'd gladly see you replaced if you refuse work under the management constraints that would create such situations. The orgs been owned by corporate interests since the 90s. It's why they'd rather the individual developer be morally thrown under the bus as oposed to the company.
In the UK the engineering profession (including the software industry) is overseen by the Engineering Council, which has delegated authority from the Privy Council on behalf of the Government. The Council, together with the Royal Academy of Engineering, promotes a Statement of Ethical Principles. These flow down to the ethical codes of conduct at institutions such as the British Computer Society and Institution of Engineering and Technology, and many of the people concerned with Horizon will be members of these or other institutions. It concerns me that at least some of these people must have been aware of conflicts with the eithical commitments to which they signed up.
I've worked in Health IT for 20 years and frankly I think what we see is the tip of the iceberg. There just isn't what you would call a safety culture like we see in other high risk industries. I've banged the drum of good governance and safety within software development companies and received blank stares or worse arrogant waffle from directors who are clearly out of their depth and covering their ass. Then come the toxic managers shouting people down, and then before you know it, the product manager, the developer, the tester, all keep their heads down. I have had employees beg me to not say anything "it will just create problems". It's a shocking attitude and culture. People have and will die.
Like the deadly THERAC-25 software incidents?
Last big client I worked for as consultant, I was fired for not timely delivery (but nobody really pressed a deadline)... I think though, it was, because I started asking too many uncomfortable questions and proposing to address the remediation of found IT risks in the official requirements for addressing further in project ... It was my job to assess the IT risk, but the management did not bother me to comply with task description.
How can a £1 billion software project have only 8 developers? I've never worked on any project that big, does anyone know where all the money goes?
It was a SAAS project.
The 8 developers were just the programmers on the EPOSS team, only one module of the overall system, however the most critical for the sub-postmasters as it handled money-in, money-out.
I have conducted numerous security consultations for governmental agencies and healthcare public management systems following the enforcement of the EU GDPR law. The overall structure is remarkably poor, with end-of-life servers, no security patches for years, a lack of basic code security policies known to most coders, a non-standardized use of prepared statements in parametric SQL queries and many more horrific things.
Thank you so much for this helpful explanation. I'd love to know more about the help desk data... calls to the desk must have recorded in detail, exactly what was going on in the Horizon system. Somebody, somewhere must have got up one day and decided to limit the spread of that data. I'd like to hear evidence from that person, in which they explain their decision.
Unbelieveable. We know such systems are complex and may have bugs. For this kind of bugs a look into the logs would have been enough. If I see several transactions with repeated data within a small time frame, then we likely have a problem. Should be a piece of cake to write some SQL to filter those out and then compare with the real money to see that this adds up. It would be still a tragedy, but at least it would have been possible to find the cause and fix it and not push those poor guys into the court and often enough into jail.
I wish the managers would go to jail for such behavior. In the end, small workers go to jail, but the managers just pay with the money of the corporation, money that is not their money after all, just like politicians.
As a complete layman with no prior knowledge of the subject but followed the unfolding post office enquiry with interest, your explanation of this complex subject area was really informative. Well done.
thank you, I am pleased that you found it helpful
Critical work should NEVER be given to people who are just starting or average. UNLESS the people who are allegedly Masters, look over it and confirm it works.
Those critical parts need to have signatures behind them. That developer...everyone... needs to know their system failed so it doesn't happen again.
If an initial company builds a product and sells it to a third party and after some time the third-party reports there's a problem; that company needs to fix it fast at no charge. I'd say for the first 3 years of the product.
However, if that third party knows there's a problem and does not quickly report it and stop the use of the software just to keep the company moving forward. THEY ARE RESPONSIBLE!!! They know a serious problem is in the software. They are willingly ignoring it as if it is a minor inconvenience. They've had multiple reports from multiple employees and still have done nothing about it.
How about this, automated testing? and don't spare people's feelings, if you can't handle being wrong then find another job, Instead we have to massage people's egos and tiptoe around causing offence. Months go past without addressing stuff because no one can just say "Module X has an error cause by this function"
it's gov procurement I'm sure they found the cheapest devs fujitso could bring through the door at 1/5th the contracts bid price.
Thank you for explaining this. One of my English friends was telling me about this post office scandal, and I'd wondered how it all happened, plus this brings back fond memories of database and OS classes at university 😊
I'd never heard of all of this before a couple of days ago. It's... gobsmacking. The lengths people in positions of power will go to to prop up their structure - lying, cheating, etc. It's very sad. Sometimes you just have to fall on your sword. The thing is, though, in this case - at least in the beginning - no one even needed to do that. All they had to do is lay down the law to Fujitsu.
Really nice video, takes you through both the info on the scandal and also some of the nitty gritty details on distributed systens, which I much appreciate
In my company we had weekly reviews. These were code and hardware reviews and all developers attended. Any new code written by anyone that week was reviewed by all others (usually senior devs did most of the commenting). The code was criticized by anyone and everyone. The junior devs got their code torn apart for the first few months but it was done in the spirit of the 'greater good'. i.e. making the code better. But it also taught everyone in the group a lot. The code reviews would take 1/2 a day a week (and sometimes several days if a new design review) and may have caused the development time to be 20% longer than it could have been if 100% of the staff were top devs, but by the end of a project we were all good top devs! It was especially good when a junior dev could point out some issues in a senior devs code - gotcha! We could also ask q's like 'I don't understand - why is this code necessary', etc. and we weren't derided for it. We were lucky in that management saw the value in these reviews and didn't try to axe them, even though towards the end of a project, there were hardly any code issues found because we had all got so good!
I'm a software developer. The bugs you describe so well would have been fixable (one Fujitsu developer was arguing to rewrite the cash account module, for example). What's shocking is that instead, they were lied about at various levels of the institutions involved.
It's not the bugs that really cause the problems, it's how the people deal with them.
We as a profession do need to shout loudly when we see this kind of mismanagement: not just "I see bugs" but also "I don't think this organisation is managing bugs properly". Something equivalent also applies to lawyers, of course.
Will this be the same committee examining the closure by the post office of several thousand post office accounts used to pay the most vulnerable blind severely disabled children and adults who have been left destitute,starving, hospitalized as a result they have not seen any income since 2nd june 2022. Will the group compensation for this legally protected group who have had their lives threatened also come from the Fiijitsu compensation scheme?
Will the collapse of the horizen system effect the payments of disability incomes through the post office branches since June 2022 ? under article 11 for human rights for those with disabilities the legislation under the European convention make immediate settlement to these sorely disabled bling adults from the monies allocated by Fujitsu ?
There are I thing two distinct scandals in this whole episode, although I guess they are related. The first one was that not only did ICL as was generate what was obviously a shoddy product but that who ever was responsible for accepting it at the Post Office did so - even though we now know the pilot rollout itself suggested there were issues. The second scandal was that both the Post Office and Fujitsu (as they had become) colluded with each other to seemingly commit perjury - claiming on witness statements that there were no known relevant defects with the system when the inquiry has established that there indeed known problems at least some of that time. This is not only pretending a system was working better than it did, it was doing so to a court at a criminal trial. Whatever the motivation of the Post Office, were Fujitsu that desperate to hold onto a contract?
It sounds like there's an even bigger scandal, in that once all this was discovered, almost nothing changed - until politicians were embarrassed by a TV programme.
Developers absolutely should have a duty of care consistent with the potential impact of their work. The main hurdle to overcome is the establishment of a licensing body such as the Bar for lawyers or the Medical board for practicing Physicians. Industry will lobby hard against this as it would reduce the seemingly already insufficient pool of developers, thereby increasing the cost of said developers.
I myself am a developer, and I hope that we can establish such a body as it would enable better protections for the public. We would finally live up to the name "Software Engineer". The biggest improvement will be the establishment of an authority to which concerned developers can report incidents to beyond mere fraud or lying to investors.
8 software engineers on a £1 billion software project. That says everything to me. With terrible UK salaries, that would be less than 1% of the budget spent on software engineering.
I'd be very surprised if any of those 8 ever claimed the system was bug free.
I’m doubtful how good the “good” software engineers were if they couldn’t create a culture to level up the rest of the team to also be good. Though bad middle managers could stop such a culture developing.
"I'd be very surprised if any of those 8 ever claimed the system was bug free."
I once saw a report which claims that there is a mistake every ten lines of code (twenty lines for military and nuclear systems). This is for fully tested systems which are certified to operate exactly to specification.
I once was involved with a company making automatic machinery. A customer had a mysterious problem which no-one else using the same kit for the same task had reported. The machine would function perfectly for about six months and then "mysteriously" crash. Turned out that this one customer never powered down their machine and everyone else switched off at the weekend. The bug was due to a tiny memory leak (one byte per transaction).
I've had something similar with a system that was always on. It's a complete nightmare to work out the cause of a bug that you can't replicate.
The library we were using for websockets would fail when left on for a week due to them using the wrong type of reactive extension subject in their connection failure retry logic, which they never fixed or allowed a PR for to be merged. That was easy to find and fix. We replaced it with our own retry logic but sometimes that would fail (once a month for some test users). The cause of the second was if the ping-pong keeping the websocket connection alive failed due to say a lost packet, TCP would retry after 3 seconds. However if the TCP retry packet was also lost, the ping-pong connection timeout was set at 5 seconds instead of the default 20 seconds, so it wouldn't retry again. So the connection would fail if two packets in a row were dropped. That was happening for some testers who sat the device on top of their routers due to WiFi interference. The lost connection retry we created in code was working fine but about 1 in 100 times there was a race condition in the logic that restarted the websocket connection: it was attempting to connect to the remote device before the websocket client had finished intialising on the device.
The only way to uncover all this was two days spent on WireShark inspecting each packet sent and then using intuition from that to build test harnesses to simulate packets constantly dropping. It makes me think that Netflix's chaos engineering simian army might be something that could catch that kind of extremely rare bug. It's a pity there aren't more open source tools to do that kind of testing. I wonder if AI LLMs could help discovering those kinds of bugs or creating test scenarios to find them.
Even given the shenanigans between the PO & Fujitsu, how did it manage to go on for so many years? Was there no honest customer who would back the PO Official that the transaction was for 8K & not 24K in the example you cited? In comparison Boeing 737 Max “bug” if it could be called that took 2 crashes - 1 too many & a lucky break with the third incident providentially thwarted allowing the working backward & nailing the MCAS issue on an intact plane with all recorded data to support the findings. The MCAS was a kludge to fit a larger more energy efficient engine on essentially the same fuselage which caused potential stalling due to the new CoG & it got hardcoded into the logic to push the nose down especially on take-off without any override input possible by the Pilot. The FAA was hand in glove with Boeing management essentially letting the lunatics run the asylum. The parallel with the PO/Fujitsu case certainly resonates with the former. It is the innocents that always end up paying the price. Technological development is all nice & good but it should not always be the innocents that end up paying the price of any & all Mistakes that invariably roll down the chain from the very top. In essence the concerned top most officials should be criminally charged & face jail time or worse for failing to exercise duty of care. If they simply get the equivalent of a slap on the wrist, it just sends a message that such behaviour is fair-game especially as they could get away with it at little personal cost. Because there is a cost involved on the other side as well - that of wantonly cutting corners in Boeing’s case at least so their share price could rise by a few more millions come earnings declaration time.
Thank you so much for explaining - can you summarise the alleged 30 or 40 Horizon defects.
Were any sub post offices unscathed - assuming the sub postmasters did not continuously cover (false) small losses out of fear ?
Were crown post offices affected and their postmasters also prosecuted or disciplined ?
Finally could any post office actually have a net profit from these errors ?
I am 60y and have built (or was PM for building) many financial systems (or interfaces) with similar properties. IMHO the lack of proper testing is MUCH MORE to blame than the builders! Errors CAN and WILL happen even with very good builders. Proper testing protocols should be able to catch these errors. And what I do not onderstand is how the "creation" of money was never caught.
Well I think that perhaps that is a difference of semantics, I am a proponent of Continuous Delivery, and in it "proper testing" is an inherent part of software development. So when I talk of this being a failure of software development, that includes proper testing, because I don't believe that you can do an effective job without proper testing, and as a CDer I also believe that you also can't delegate that responsibility to other people, it is part of professional software development.
The testers found thousands of bugs, many critical, but the management pushed the software out anyway. Watch David McDonnell's testimony.
That is a masterly statement of the nature of the technical "problem of Horizon". The failure to insist on the highest standards of coding competence in so ambitious a project is deplorable. But stepping back a bit, I cannot see why such a critical system was put out to tender for a single bespoke solution, when several government departments were the "ultimate customers" (e.g. the DSS, who pulled the rug early in the development). That must have lowered the quality of the system requirements definition from the outset, In operation live, it seems to have led inevitably to multi-level towers of administrators in Fujitsu and the PO where communications both across and internal were spasmodic, and responsibility could always be shuffled to "somewhere else". And this in a bureaucracy where "don;t rock the boat" seems to have been the universal management answer to so many concerns expressed by technicians.
Thank you very much. You explained the problems of transaction processing so well. I've been trying to explain the issues you highlighted to friends and yes you don't even need computers for transaction processing to get really challenging.
For example if we are both sat at a table and I give you £10 over the table and you accept then that is a pretty pure and successful transaction. However if you are in another room and you dont want to be disturbed and I slide the £10 under your door how do I know you have received and accepted it. You might, for example, say thank you but are you talking to me or someone on the phone, etc. etc.😊😊
I am a Sw person trying to get a handle on the horizon tech detail. LAN in office WAN above that, interrupted deliveries, lost ones, partial ones, journal all. PLEASE get to the detail. I'll check in regularly with you, don't let me down, all best Jo
I was working as a network technician for a large Telecoms service company installing a VOIP system for a global insurance company. A lot of the so called Project Managers had no technical knowledge and were unable to understand the cause or effect of problems created from time to time during the install. They had the power to throw us off site if we tried to raise concerns and stop them doing something that effected the live network. It was a very messy project.
It niggled the hell out of me that these guys were on astronomical rates.
I imagine the Horizon project is no different.
As a retired one-time s/w developer, whether some developers weren't good enough, monitored etc , it's really a problem about inadequate management re: evaluating human resources & requiring a robust & comprehensive software/system testing regime. And Royal Mail has to take responsibility for just taking Fujitsu's word on all of this. They needed to have a major involvement in the testing process. They called it customer acceptance testing, when I was in IT. The customer being Royal Mail IT implementers. If the duff coders kept on having work farmed out to them, how were they to know what was acceptable & what wasn't.
This is definitely a processes issue. We can't ever completely avoid having bugs, so in any normal software development there needs to be both a process of thorough testing and a process of bug reporting, triaging and management. For something like this they probably needed to put a complete hold on processing any transactions, assembled a team of senior engineers to drop whatever they're working on and stay up until the problem was resolved. There should also be open and effective lines of communication in both directions with the customers and all stakeholders to keep everyone updated on what the problem was and the plan to get it resolved. It's somewhat baffling that none of this happened.
Nicely explained. I previously had watched a computerphile video on this system but enjoyed this one too. I used to program for a living (wouldn't go as far as calling myself a software engineer) and I enjoyed the challenge and the creativity of writing programs but on larger programs I frequently felt out my depth at times and can relate to your point on how it "one of the more complicated things that humans can do" In the end I chose a different profession partly for this reason and partly for the money i.e. In my industry some of the users of the software were getting paid better than the developers!
It's not clear as to the extent that funds were lost due to accounting bugs or the ability of others to alter accounts via widely reported remote access being open.
I've read comments suggesting there was no transactions implemented for the systems at the branches. No idea if that's true but would be a fundamental design error rather than mere bugs.
Also suggested, poor version control of schemas between the apps and databases.
Whose responsible? It's not the 6 inexperienced devs but the leads who hired them, and the management who covered it up.
I've worked on many late and overspent projects but this is better and cheaper than delivering substandard software, LDs and all. On one project, we scrapped what the previous team had spent 2 years working on and started again, gave the management a fright but within 6 months I was on speaking terms with the CEO of the multi-national company.
Starting again isn't always the answer especially when requirements capture is a problem. On my current project, we've incrementally taken it forward to achieve what effectively is a new product.
How often was I told by my superiors that we should hire more engineers and not fewer. That we could hire cheap ones out of college and then teach them. Nvmnd spending time fixing their bugs if we caught them in time, or even more time fixing the damage they’d caused.
I’ve come to believe that the issue is the Dunning Kruger effect - to someone who doesn’t speak Spanish, a beginner with good pronunciation will sound like a Spanish speaker. Since few executives understand much about coding, they tend to manage towards the wrong objectives 😢
Excellent summary. 25 years in ERP PM and consultancy with a couple of bespoke projects in there, nothing is new or unique in this case. The scandal is the continuous coverup.
What I will add that this will only get worse as more and more support and development moves to countries that provide cheaper rates... like India.
Having outrageously high rates (like in the USA) really do not correlate with code quality: it just correlates with cost of living there. Your pointing fingers at India is borderline if you ask me.
One big advantage of today's internet (and social media in particular) is that there now is communication between ordinary people, and thus between victims!
In the past, when you would report a problem with a product (including a problem in software) to the manufacturer, you would usually get the "you are the first one to report that!" reply.
That would give them the opportunity to hint that "it isn't that important" and "it is probably your fault".
But now, people post problems they find on social media. Others read it, and quickly it becomes apparent that multiple people get the "you are the first" reply, and thus the company is LYING.
The fact that this often escalates quickly makes it more difficult for companies to cover-up their mistakes. It would certainly have saved a lot of grief when victims of this problem would have aggressively published their experiences, so that outsiders would have seen the pattern.
It really is baffling that the terminals (and post-offices) didn't keep independent ledgers. Of course that would not fix the click again issue (for that the form would need resetting before enabling the button). And if course there should be separate till receipts.
Typically when taking over new software/hardware teams in product development, I tend to find ... No internal operating standard that stick to measureable and consistent coding conventions. - Even if there is a standard, they dont stick to it. Bad mission planning, Distracting workplaces that attract mishap and error. Use Agile more as a tool to remove quality checks and balances removing scrutiny. Not checking "edge-cases" when making changes and/or using complilers, Poor - or even no testing practices in deployed state out in the field....btw , love the T shirt written in "Quake" speak.
Quality video, very well sir.
I find the lack of communication about these bugs to the security team shocking. There was a wall of silence between the people who knew about the bugs, and the people who were investigating the finances. If I knew about both of these things I would have arranged a meeting between both, but what happened is that the Port Office management, actively kept these two groups separate to save brand reputation. Those postmasters lives were not worth ruining for the reputation of the Post Office.
Software is increasingly important for society. We all rely on it and have no choice but to trust it every day -- it's everywhere, from a silly child's toy, to our boilers, to the cars we drive. Yet every developer here could tell horror stories of rushed development and hacked together code. These aren't rare situations, our industry is rife with it. It has to change.
If software companies were held to the same level we hold chartered accountants or other professions, where a high standard is expected (and where low standards could be dangerous) things would be different.
Companies would have no choice but to give developers the time and resources they need to do a good job.
This problem is only going to get worse as software gets more and more integrated into our daily lives. It's time our profession matured to the next level. Situations like in PCL/Fujitsu, where half a team were "incapable of producing software at a professional level", should never be allowed to happen.
Even if software companies were expected to keep several year's worth of commit histories for their projects, just like finance departments are expected to do for company accounting. That would be a start. (It would have changed everything for the Horizon scandal.)
Issues happen, bugs happen, bad software happens. But it's usually incompetence not malice. Cover ups ruining the lives of people? That obviously happens too, but it's always malice, never incompetence. And that behavior can and should be disincentivized by simply throwing anyone found guilty in jail. When worrying too much about the bonus comes with the possibility of up to 25y jail sentence, people will think a bit more before taking that leap.
I think there must be some people with rather weird psychology involved. Most people, when given the choice between bad and worse, choose bad (expose the issue, instead of standing still and waiting for it explode on their face with 100 x force).
3:36 "980 of their own employees" - nitpick: subpostmasters are not employees of POL, they are self-employed franchisees - which is why they are treated as second class citizens within POL.
There was an imbalance of authority and agency in the Contract between Post Office and sub-postmasters, I believe we may yet hear more about this in the Horizon Inquiry. I struggle to understand why the National Federation of Sub Postmasters didn't seem to challenge this, although the funding of the Federation by Post Office may have something to do with it.
We desperately need some conversations about ethics in the software industry.
Unfortunately, us engineers cannot do this alone, and companies are usually solely evaluated based on profits for shareholders, and that often leads to a race to the bottom or harmful practices.
What we can do as engineers is be professional. Hold ourselves to high standards, push back when things are wrong. Otherwise we will be regulated from the outside, with all the problems that will entail.
A possible starting point is the Code of Ethics at the British Computer Society.
In any 'normal' (read: ideal) software project, there is an accountable person who acts as the owner of the finished product. Where the product is complex this may be filled by multiple responsible persons, but there is still a single actor who is held to ultimate account for performance against a set of black box behaviours which should include as a minimum: reliability.
The most confounding thing about this whole wretched affair is that we still haven't seen a single person identified as the ultimate product owner - yes we have directors, projects leads and customers ... but no one who was supposed to be the advocate for the end user.
I'd like to recommend a book to engineering managers and executives in Post Office and Fujitsu - "It sounded good when we started - a project managers guide to working with people on projects", by Dwayne Phillips and Roy O'Brien. And anyone working on large, complex and long-lifed systems which need to be supported over extended periods like 20+ years needs to have a look at BSI's PAS 280:2018 "Through-life engineering services - Adding business value through a common framework - Guide".
Agree with everything you said, but one thing that just blows my mind as a database developer who has worked on many complex systems that were probably less important (but we're very robust in their implementation within a team) was it doesn't seem to be as though the Horizon system could have been rigourously tested, if it was tested at all, before signoff and rollout. Having professional experienced testers surely was absolutely necessary on this project whose job was to try and break the system in every circumstance possible.
As a distributed system this should have in part replicated how the system would work in practice. None of this can have been done to any level and although you could have developers developing using TDD practices i think on projects this important you need a separate tariff team. This probably would have pushed the cost up and therefore less profit or maybe not getting the contract in the first place (and another company with exactly the same issues building it instead, so basically a lottery).
The cover up and accusing sub postmasters of basically stealing money when the bugs were known from many past offices, and the ruining of people's lives, is beyond criminal though. Those people who did this need to go to jail.
It's an old system, testing edge cases around transactions automatically back then was almost impossible, it still is pretty hard and you must know what your are searching for, most developers do not consider "non-functional" (it's obviously functional) stuff like failed transactions because they copy pasted three (actual conflicting) annotations from stackoverflow after they saw a "no transaction active" error. You need great people in the team to catch all those issues and establish a culture, where people understand how stuff works under the hood and how this can be tested.
And this is not really a time/budget issue, in most projects you have endless time, if you know what you are doing. "Not enough time" is mostly an excuse for bad staffing, bad priorities, lack of capability and knowledge and mostly "work extends to the available time" (Parkinson's Law). I just reviewed a project, where the lead architect of 30 mostly freshman near-shore developers (...) spent most of his time with fancy cloud service POCs instead of establishing any kind of "software architecture" or testing/quality guidelines -> the software was bug-riddled and basically not maintainable anymore after not even 12 months of development. Proper testing is not something you discuss with management, you just do it or you will lose so much more time later - and maybe ruin peoples lives. Skipping testing is like leaving out screws and bolts while building a car to be faster or have more time to slack - it's non-negotiable.
The testers found thousands of bugs, many critical, but the management pushed the software out anyway. Watch David McDonnell's testimony.
@@snakeplissken526 Didn't know that, which makes it even worse. Some of those running the organisation that knew about this at the time and basically defrauded the managers accused of stealing from the Post Office, as well as causing such physical and emotional distress that some were impacted massively, should be in jail.
The fact that our current (corrupt) government ministers don't bring anything up with Fujitsu even now all this is out in the open, and they are still favoured by our government and paid huge sums in government contracts, is just disgusting.
Hi Dave, it's Garry.. Great video - Failing debounce, ACID and Locking issues. How it is possible that this wasn't picked up in testing...
Would you be able to do a follow on video?
What SDLC model did Horizon use
What CI/CD process did they follow
How did they test the systems (Is it true they had no UAT, Staging platform)
Finally how might Continuous Delivery processes help identify these issues
thanx again
I looked for those details, but couldn't find them. Based on when the project started alone, and the results, I would be surprised if the project wasn't run as a waterfall.
CD would certainly have helped, and did when I was part of a team that built a large distributed PoS system at roughly the same time.
We simulated and tested failure scenarios to make sure that no data was lost, or created. We made explicitly sure that you couldn't resend the same request until the first attempt had been sent. Not all of this was CD, some of it was just common sense.
One of the things that I find worrying is that they were still still prosecuting users for the same problems 10 years or so after the first instances. How could the system still have the same known bugs after that time? That has to be mostly down to Fujitsu as a company, although the Post Office should have chased them mercilessly until it was right and it appears that that was the one thing they did not do.
Software companies should be financial responsible for their bugs. They should insure their software . If they have a good quality management, they pay less for their insurance.
Frankly, financial responsibility for damages due to bugs should have been explicit in the contract. Based on my experience in the software industry, I'll bet it wasn't spelled out in the contract. Some of these software contracts are very poorly written and fail to account for negligent damages.
In short, the code was poorly written, but I'll bet the contracts were also poorly written. That's why companies keep getting away with things like this.
That will make software a lot more expensive. Not a good outcome in a lot of cases, it depends on what the software is for. And how do you handle people contributing to open source software? We’ve had a few high profile and far reaching security issues recently, due to tiny bugs in open source libraries.
@@kaasmeester5903 Not the people who are contributing to software are responsible but the companies. So if you write a small library, you are not resposible for the bugs, but the company who uses it. The company has to ensure that the software quality is good.
A big open source project has to reject bad software for deployment.
@@kaasmeester5903 I agree. That's why I point to contracts as the solution here. The responsibilities and liabilities can vary. Most open source software is provided under a license that limits liability, because it's free. On the other hand, if I'm paying your company large sums to provide software, then I need to specify in the contract what I expect you to do and the consequences of failing to fulfill that contract.
It's perfectly possible to devise incentivised or risk-sharing contracts between a software developer and their customer. Actually, the Post Office actually pursued the insurance route when they warned their insurer that there was a risk that there had been miscarriages of justice. This pre-dated Ms. Vennells evidence to a House of Commons select committee in which she denied that Post Office had any knowledge of bugs, errors or defects that could have assisted sub-postmasters with their defence.
"Who should be responsible when crap software hurts people?"
I think we already know the answer to that question.
Its the same answer for similar circumstances such as a plane falling out of the sky because a defective part fails off, a drug causing birth defects, or a make of car bursting into flames in a minor accident due to a petrol tank design defect ..........its the manufacturer of those products that caused harm by being defective.
Of course, there are multiple "harms" in this case.
Fujitsu are responsible for the defective software that caused harm, and the Post Office are responsible for the harm caused by the Horizon system being faulty, and the further harm caused by their doubling down and trebling down on their deceit by denying those defects, informing people that they were the only occurrence of such defects, and the subsequent prosecution of individuals thereafter despite it being known that the system had issues that caused financial loss to incorrectly show up in local Post Office accounts.
There was also the lying about being able to remotely access individual local Post Office systems accounts and alter transactions!
The Post Office have "hurt" the Post Masters using the Horizon system and Fujitsu has hurt its own reputation and also that of the Post Office.
I think the blame lies much more with Post Office management than anywhere else.
Anything can be faulty. But blaming the faults on your own employees and telling them they are the only one that have cash differences while you are handling 980 such cases is unforgivable.
(in fact this number is so high that the justice department is not free of blame either - someone should have noticed that the "you are the only one" accusation is used in 980 different cases)
This is depressing. I’ve always wondered how people can use and abuse people beneath them just to satisfy their bosses. Probably why I’ll never be in senior leadership.
As you mention. The scandal isn't that the software failed - the scandal is the fact that the the corporate machine falsely prosecuted for fraud, innocent employees that had nothing to do with the failings. These prosecutions led to multiple people being incorrectly imprisoned and, in several cases, directly led to suicide.
You can blame the software developers for developing software that didn't meet the requirements but that's hardly a scandal (and quite commonplace, actually). Under those conditions, the worst case scenario is that Post Office would have paid a load of money for software that didn't work, but in of itself it wouldn't have led to multiple imprisonments and deaths.
I'm finding myself adding more and more videos of yours to my Architecture and Engie favourite list, I might as well just add the channel at this point :)))
Blame goes to Fujitsu management, for not providing the resources and people to write better software, and for covering it up - But note they dealt directly with the Post Office and did report it to them
The Post Office management knew they had a buggy system, and could have blamed Fujitsu publicly, but instead actively covered it up - that's the real scandal
It is understandable that people are at varying levels of competence. It is not understandable that people with insufficient competence would be let continue to work on the project.
It not only can lead to real harm (it did), but there is a significant risk to a company's reputation (Fujitsu). Additionally, Fujitsu could also have risked losing money, if Post Office demanded that material quality issues had to be fixed without additional compensation.
However, prestige projects, where perhaps a preferred partner is the only bidder (other companies thinking there is no point to bid if the decision has already been made) is not going to improve on software quality.
It seems like the bug was a source of revenue for the managers (possibly in both companies), so that they had a good incentive to cover it up.
As always this breaks down the issue perfectly and I'm not a developer. Thanks as always. 😃
I meant to say in my other screed, thanks for the video, I think I might be hooked on your channel :-)
You're welcome!
The more worrying failing is that of the justice system that let innocent people be convicted, and I don't hear that being discussed, interestingly.
As an amature software writer from 1980s to the present day, what has got me baffled is that no one, as yet, has mentioned beta testing of Horizon. Was this ever undertaken? If it was then it would have been known that Horizon was not fit for purpose before it was rolled out. This would add another level of evil intent on the managements of the Post Office and Fujitsu. I hope that someone connected to the Hearing reads this and ask the relevant question.
Well, one thing that adds fuel to the fire is absence of training in companies and requiring the developers to “hit the ground running” (as they put it in job ads). Developers, no matter how much expert they are, need to be given training about the related tech, system design, and approach they should take.
Secondly, since non-technical people do not understand that a softwares are as complex to write as building a skyscraper, or inventing a new type of car. Since they think that a software developer, like an office clerk, just sits on a chair and presses some keys, so they can apply the same “pressure tactics” on software developers to get the job done more quickly as they do with clerks. Result, softwares written in a hurry are badly coded, have bad design shortcuts, and end up buggy and unmaintainable “spaghetti” kind of state. And then the bugs like this happen. Unrealistic deadlines, undue pressure, and non-tech people managing and supervising teams are equally responsible for this mess. If I hire a driver to get me from A to B, and I require him to cover distance of 100km in half an hour whatever happens, everyone knows what will actually happen.
Agree its complex, its basically a mini silo system (tills,servers,etc.) running on each post office branch. The volume of branches and the number of bugs compounded the problem. I've watched a few evidence videos so far. Some of these issues like locking, transaction data sitting on dead hardware is typical. Throw into the mix that most of the people involved worked in the Post Office and Fujitsu for 10+ years hasnt helped....lack of experience and skill you get from different roles.
These days senior management lack any technical expertise to understand software development problems.
The volume of manual steps involved in the extraction process seems to be no ending and most of it was ignored or not practical.
The funny aspect of this is that extracting audit record data, we seem to miss that this was raw level transaction data which your average subpostmanager probably doesn't have a clue to summary given it was probably sizeable in nature.
I've dealt with polling and EOD from a head office point of view, typically you have missing days and even missing hours when errors occur and that doesn't factor in chasing polling issues at stores, etc.
Horizon and its successors have the most appalling design, build and test. Having put in many distributed banking systems the steps in design, build and test were always independently audited. The architects need to be held directly to account for the abysmal design as do those that tested it. As a programme manager, I get rid of those people that did mediocre work because it would cost heavy in test and production those for their weak code.
As to Fujitsu, the government should insist on a full audit of all their systems and require Fujitsu to disclose every piece of material right up to the board.
Previous Post office and Fujitsu directors and senior management should be immediately banned from holding any senior position unless they can prove no role in this mess. And then sued for all their wealth to pay the post masters. Gaol time for anyone that was a party or did nothing knowing about the deception.
THE METROPOLITAN POLICE HAVE FAILED IN THEIR DUTY AS WELL. THE COMMISSIONER NEEDS TO ANSWER FOR THEIR CORRUPT LACK OF PROSECUTIONS. Excuses that the inquiry needs to proceed first is utter rubbish. Criminal matters do not wait for civil matters.
There are some things about the Horisozon Scandal that don't make a lot of sense to me.
1) Why was there an assumption in court that the computers were correct? If the code were perfect, you'd never need hotfixes - but I bet Fujitsu wrote some. And given that my phone, PCs, TV, and even my car nag me to install updates - who imagines that a distributed payment system of that scale would not have bugs? Even a moment's thought shows that this assu
is likely false.
2) Why, in all those court cases, was the bug tracking system not made available through disclosure? That will tell you about the quality of the code. "You say your system operates perfectly - okay, let's see your issue tracking system". And if they don't have a bug tracking system, that will tell you about the quality of the company.
3) How was it that so few developers who'd worked on it fail to blow a whistle? (Side note: at least one did)
Developers deserve a lot of blame here. Of course they are not responsible for the corrupt procurement process, not responsible for the "never admit any failures" MBA culture, but they really built an exceptionally crappy system, even by the British standards. And for this they must be hounded and mocked. Far too often code monkeys get away without their incompetence being exposed and laughed at. This is the time to beat some fear into the bad pseudo-engineers and to remind them what respinsibility is.
Bugs happen, but such bugs should be catched in QC (fast clicking buttons is a typical error scenario, it should be transaction safe anyway) or at least someone should have do a deep log analysis, after such things happen more often, and file a bug report. Should be easy to find duplicates in the logs.
@@davidjulitz7446 systems like this should never be bult without using formal methods. And formal proofs woupd have demonstrated very early on that the design itself is inadequate. There is no point in chasing and fixing small bugs when the overall design is utterly broken from the very beginning.
@@vitalyl1327 Not sure how to do formal proof for a software system of a decent size? However, maybe there were weakneses in the architecture from the beginning (I don't have enough information about that). But also in this case you cant just blame the devs alone.
The point is, that it should have been possible to detect this error in QA or later in production. So there would have been the possibility to not go live, to fix it, take it offline or whatever. But they preferred to assume the system works always correct and to accuse the user for doing wrong.
@@davidjulitz7446 it is a distributed system, formal proofs of soundness are indeed possible (TLA+ or simialr). And yes, lack of QA loop is also developers fault. They shoudl have raised an alarm and decline to work in such conditions.
@@vitalyl1327 especially for distributed systems with all the software and interfaces in between such a proof will be nearly impossible. It's already hard for non trivial real world single threaded software.
And most people wouldn't leave their well paid job because the management is shit. By the way Fujitsu is not a no name.
I think your demands are theoretically right, but unrealistic.