The only tool we have to guarantee the software works according to the specification is formal verification, and formal methods are a PAIN to use and are extremely limited in scope.
For the rest, the best we can do is “hope you thought of everything” (aka manual and automated testing) and “have a colleague look it over” (aka code reviews).
And that does not even start to tackle the issue that is making sure the spec solves the problem in the first place.
Yes, all the other things you mention are true too. But you were set up for failure from the start by the gods of intractable complexity first.
Go read up on the development process NASA uses. It’s obviously possible to do development in a way where you focus on quality. It’s simply not profitable to do that. Tools like formal verification methods are in no way required to guarantee high quality of software. Even having good testing practices can get you very far. Meanwhile, ensuring the spec solves the problem in the first place is again a matter of moving more slowly and deliberately.
No, my retort is that we have real world examples like NASA, showing that you can design software using a different set of priorities. Nowhere did I say we have to be very careful. What I said is that you have to have a different kind of process. Try to engage with what’s actually being said to you instead of making a lazy straw man.
That’s grade A horse cap.
The only tool we have to guarantee the software works according to the specification is formal verification, and formal methods are a PAIN to use and are extremely limited in scope.
For the rest, the best we can do is “hope you thought of everything” (aka manual and automated testing) and “have a colleague look it over” (aka code reviews).
And that does not even start to tackle the issue that is making sure the spec solves the problem in the first place.
Yes, all the other things you mention are true too. But you were set up for failure from the start by the gods of intractable complexity first.
Go read up on the development process NASA uses. It’s obviously possible to do development in a way where you focus on quality. It’s simply not profitable to do that. Tools like formal verification methods are in no way required to guarantee high quality of software. Even having good testing practices can get you very far. Meanwhile, ensuring the spec solves the problem in the first place is again a matter of moving more slowly and deliberately.
I love it how basically your only retort is “but we think really hard about it and are very careful”. Which is exactly what I just said.
No, my retort is that we have real world examples like NASA, showing that you can design software using a different set of priorities. Nowhere did I say we have to be very careful. What I said is that you have to have a different kind of process. Try to engage with what’s actually being said to you instead of making a lazy straw man.