This is a manifestation of almost everything wrong about software development and marketing practices.
I work in hardware development and such a failure is almost impossible to imagine. It has to work, always. It puzzles me why this isn't the casebfor software. My SWE colleagues often get mad at us HW guys because we want to see their test coverage for the firmware/drivers etc.. The focus is having something which compiles and pushing the code to production as fast as possible and then regressing in production. Most of HW problems are a result of this. I found it's often better to go over the firmware myself and read line by line to understand what the code does. It saves so much time from endless debugging sessions later. It pisses of firmware guys, but hey, you have to break some eggs to make an omelette.
> It puzzles me why this isn't the case for software
In my anecdotal experience, its because corporate software projects are not typically run by people who are good at building safe things - but rather, just building things quickly.
There's a huge issue with the mentality of "it works, ship it" being propagated.
I build systems software for safety-critical and mission-critical markets, and I can say without a doubt that if there aren't at least two quality stages in your process workflow (and your workflow isn't waterfall), then you're going to be in for a rough time, rookies.
Always, always delay your releases, and always, always, eat your own dog food by testing your delayed releases in your own customer-like environment, which is to say, never release a developers build ..
This is also my experience. And the worst was always being lectured by SW project managers about being agile and having to move quick and release early. I won't release anything without making sure everything works in every possible condition. This is why it takes years to build a complex chip (CPU, Fpga, any SoC really). Their firmware is often squeezed into months, and often the developers are handling like 10 different projects. So, no focus, no time to understand the details of the design. At the end it's common to have firmware issues in the first year after release. It's kind of expected even.
Complexity. As you get further from the driver and the kernel software complexity expands massively. It gets to a point where it is beyond the abilities of humans and processes to manage it in a cost effective manner.
I understand that might be case for a lot of SW development. But in the context I was talking about, the HW is so much more complex than the SW. Valid for a lot of cases too. But then, why? If we know that we cannot build a 100km long bridge, nobody attempts to build that and waste resources. Why does software development lack this?
When is HW much more complex than the SW? I work in a company that designs (far from trivial) hardware, and develops embedded software, and in my experience software is always more complex than hardware, due to the many layers of abstraction (unless you are writing only, IDK, boot loaders in assembler? and even then it is about the same level of complexity)
I work in hardware development and such a failure is almost impossible to imagine. It has to work, always. It puzzles me why this isn't the casebfor software. My SWE colleagues often get mad at us HW guys because we want to see their test coverage for the firmware/drivers etc.. The focus is having something which compiles and pushing the code to production as fast as possible and then regressing in production. Most of HW problems are a result of this. I found it's often better to go over the firmware myself and read line by line to understand what the code does. It saves so much time from endless debugging sessions later. It pisses of firmware guys, but hey, you have to break some eggs to make an omelette.