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 quali

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. In software on the other hand, we're spoilt by how easy to is to fix bugs (compiling your code to generate a binary takes minutes/hours, not months, and it doesn'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're working at Google/Amazon/Apple/99%-of-software-teams, the rational thing to do is to treat reliability/testing as a 2nd class priority, not a 1st class priority. Except that there's a small number of software applications where this doesn'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'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.