As an ex-hardware engineer, reliability and thorough testing has been drilled into the heads of every single hardware team. Not because we care more about quality, but because of simple economics: finding a single major bug after tape-out is going to be extremely expensive to fix, and will push out your product launch by months. Finding a single major bug after release just might doom your entire company. Hence why reliability and testing is treated like a life-or-death priority.<p>In software on the other hand, we&#x27;re spoilt by how easy to is to fix bugs (compiling your code to generate a binary takes minutes&#x2F;hours, not months, and it doesn&#x27;t cost you millions of dollars), and also how easy it is to deploy fixes to customers (just release a patch and when someone complains, tell them to download it). Hence why if you&#x27;re working at Google&#x2F;Amazon&#x2F;Apple&#x2F;99%-of-software-teams, the rational thing to do is to treat reliability&#x2F;testing as a 2nd class priority, not a 1st class priority.<p>Except that there&#x27;s a small number of software applications where this doesn&#x27;t hold. Where testing really does need to be treated as a 1st class priority. Problem is, the engineers and managers working in these teams belong to an industry that has a completely different mindset. A mindset that translates itself into all parts of the software stack, which these engineers are then forced to rely on. A mindset that will creep into everyone&#x27;s minds, by osmosis, no matter how much they try to fight it. A mindset that works fine 99% of the time, but every now and then, leads to events exactly like this.