Not every bug creates a failure, so there's not necessarily a need to be completely bug-free. The point is to focus efforts on the bugs that can cause failure a

Not every bug creates a failure, so there's not necessarily a need to be completely bug-free. The point is to focus efforts on the bugs that can cause failure and design mitigations for them. If your system has a billion potential software failure modes, my hope is that a project manager will say the software is too complex and needs to be redesigned. I think this is where some in the software crowd get it wrong in their understanding of how software reliability in safety-critical applications is performed. There are a lot of project managers who deliberately avoid using software as a mitigation because of the complexity issue (see the 737Max use of software as a mitigation for a good example of where this practice can go wrong). So take the software example from above on CST-100. The valve mapping error should have been a known failure mode ("We command valve A and it doesn't respond." or "We command valve X and valve A responds"). Those failures are very straightforward to test for with simulations on the ground, yet somehow those errors made it into a flight configuration. Arguably, the software timer issue on that flight falls into a similar category, but the mitigations there are a bit more complex.