[extension]

Yes, we all know that this is the right attitude for certain domains of software development that have become disproportionately prominent as of late.

However, we also need software to guide rockets, monitor nuclear reactors and control medical devices. In such cases, the requirements and the end product have to be complete and flawless the first time around, or people die.

We have not figured out how to do software engineering yet. It's been fun pretending that we will never have to, but we do and we will.

[mgenzel]

Is that in fact how that happens though? Complete and flawless the first time around? I'm not that familiar with embedded sort of software, but my assumption was that they try to do a good job, but then use simulators to get the software ship-shape. At least that's what I would do, given my presumption of errors in any human endeavor. I'm much more in favor in building processes that accept failure gracefully, rather than presuming error-free production.

[extension]

Simulations suffer from the same flaw as any kind of automated testing: you can't verify the correctness of the test, except possibly with another test, which then presents the same problem. At some point, an intuitive leap must be made to call the overall process correct.

This is true of any kind of engineering, but generally the assumptions can be reduced to obvious ones with a reasonable amount of overhead. The complexity and transience of software development makes it the exception.

I have little first hand experience building ultra-critical software, but my impression is that it takes ridiculous amounts of beurocracy to bring the failure rate down to tolerable levels, making the cost astronomical and prohibiting development on the scale of commodity software.