The main issue is that software quality was generally pretty dodgy to start off with. There just isn’t any headroom to trade off.
We’re just don’t know how to reliably write reliable software. We have developed practices to cover risks we deem unacceptable, but things like the halting problem make software verification fundamentally an intractable problem.
Nah, we know how to write reliable software. That’s not the problem. Capitalist incentives are the reason software is shit. Companies race to put out products that are just good enough to get people using them. Those who spend too much time polishing their software to work well end up losing to those who put out buggy crap that’s just good enough to use. They’re the ones gaining market share and consequently locking users into using their apps.
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.
The main issue is that software quality was generally pretty dodgy to start off with. There just isn’t any headroom to trade off.
We’re just don’t know how to reliably write reliable software. We have developed practices to cover risks we deem unacceptable, but things like the halting problem make software verification fundamentally an intractable problem.
Nah, we know how to write reliable software. That’s not the problem. Capitalist incentives are the reason software is shit. Companies race to put out products that are just good enough to get people using them. Those who spend too much time polishing their software to work well end up losing to those who put out buggy crap that’s just good enough to use. They’re the ones gaining market share and consequently locking users into using their apps.
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.