31

This is horrifying. Testing code seems to have been an afterthought that ended up ruining dozens of peoples’ lives.

“Bad software sent postal workers to jail, because no one wanted to admit it could be wrong”

https://theverge.com/2021/4/...

Comments
  • 16
    "Writing tests slows me down" - "Congratulations, one of your users committed suicide."

    The more I learn about software development, the less patience I have for shitty workmanship. "But.." No, it's your code and your responsibility. "But.." No, every hour you skip on tests will turn into ten hours of customers/support/devs having do deal with your shitty bug instead of doing something productive. "But.." No, I don't care about your code; anyone can read code. I need to understand _why_ you did what you did. You need to document all business rules. When I take over to maintain that legacy hell you left behind, I need to be able to fix your shit without going insane.

    Just write the damn tests ppl
  • 2
    I hope the execs involved get buggered for eternity.
  • 1
    holy fucking shit man....
  • 10
    I dislike the article.

    It's not the bad software that sent them to jail.

    It definitely (as in without a doubt) was a human decision to sent them to jail.

    You have to be very evil to deliberately choose to not notice the softwares errors.

    Software testing aside, the softwares results should have been double checked by a human as soon as the first results came in.

    To put it simple: Blaming the software isn't right - blame should be put on the government, the seemingly non existent involvement of the justice department (over dozen of years convictions without any form of doubt?!?) and especially the lack of auditing and skepticism of everyone involved.

    Software / Computers can be wrong.

    What's even more wrong is to deliberately ignore this fact and claim that it's the softwares fault for not validating theirselves.

    In my opinion, when software in government and system critical companies would be judged and audited.... That would most likely end in a massive "we've failed miserably and knowingly put over centuries lifes in danger" report.
  • 3
    We as a society should really start acknowledging that neither we, nor our products are perfectly error free.

    There is no such thing as 100% correctness.
    Even the Factorio devs at some point started to get reports of errors literally caused by cosmic rays flipping bits...

    Bugs exist! Everywhere!

    Disclaimer:
    Yes, using a memory safe language, a fail fast approach, and good test coverage should be mandatory. But we all know, that even the most easiest and first of this list isn't gonna happen...
  • 4
    The problem here was not the software, the problem was (partly) the legal system that allowed swathes of self-interested so-called experts to wade in as witnesses on the post office's behalf, convincing the judge and jury software could never be wrong.

    It was also partly those top level execs in the post office who knew there was a pattern of so called theft that emerged after the computer system was installed, but did nothing, choosing not to put 2 and 2 together and instead finding it more convenient to wreck people's lives.

    Crap software exists and will always exist. It's pretending that your software is infallible that's the issue. Own your mistakes, and fix them.
  • 3
    @Oktokolo and out of these, the only one that might catch an error in the logic is tests and only if the error is in the implementation of the logic.

    If its in the actual logic, the tests will enforce the broken logic.
  • 1
    @Voxera
    Of course. And such a beast, that would be able to catch all logic errors, can't even exist (that is the reason, it isn't in my list).

    As stated, there is no perfection. Everything exhibits at least a smidge of uncertainty.
    So logically, the goal can only be:
    - Getting requirements as correct as possible while still getting to the implementation phase in reasonable time (implicating, that requirements are to be expected to change after implementation started).
    - Getting the implementation to match the requirements as much as possible within reasonable time.

    I would have included formal verification as it tends to catch a shiton of the bugs left by the other methods.
    But i doubt that even medical or aerospace companies are still doing that...

    The point of my list is: It is ordered by bugs eliminated per invested time - descending...
  • 3
    The timeline in the story puts this solidly in old-school thinking territory per the likely old and probably now retired or dead “Powers That Be”. There was a time, particularly in the 60s, 70s, and 80s, when people who were in charge and knew nothing about computing had a tendency to take the “gee whiz ain’t technology cool and never makes mistakes” approach. In the Vietnam war, SecDef McNamara had computer-based models of combat and logistics that he believed in more religiously than the Bible. He never permitted anyone to question it. Up to 1.4 million people died as a result. I’m thinking that management paradigm contributed to this problem in the UK postal service.
  • 0
    @SuspiciousBug depends on the project.

    If it's a chrome extension then if it works it works
  • 0
    @seraphimsystems what do you want me to say? "All code repositories under 10k LLOCs are excused from having tests?"

    If you decide to offer your app as a chrome extension, it is up against X alternative apps from other vendors. It better be working or those one star reviews are coming in hot.

    Also your app now depends on the chrome extension API. If it works now, it should keep working with canary. And the version after that. And after that. Also it should keep working with older versions (to some degree).

    Just write the tests.
Add Comment