2 ms·
The software we write is far more complex than a kitchen appliance. For simple systems, yes, test all components, build in redundancies, etc. All those things
by kqr 4y ago
The software we write is far more complex than a kitchen appliance.
For simple systems, yes, test all components, build in redundancies, etc. All those things that made reliable system design possible in the 1950s.
For complex systems you're quickly wasting your time on diminishing returns. The failure modes of complex systems lie in obscure interactions between components conditional on rare input combinations. You have to find that stuff out in production. You have to make users into testers.
However, there are better and worse ways to do this. Ideally, a failure should only be experienced by a user with a fallback solution, not a plain failure to accomplish the task entirely.
- foobiekr 4y agoHow does this line of thinking address security?
- bbjJqJmxFNbAcg9 4y agoThat's a tautology. You're saying that we shouldn't fix the complexity and bloat that gives rise to bugs because we'd have to fix the complexity and bloat that gives rise to bugs. We landed on the moon with a reliable computer and reliable software in the 1950s. What software that you've written is "far more complex" than that? (Personally, I'd posit that a lot of the complexity is the ten or fifty layers of framework and language and library between the programmer and the computer. But I digress...)
- proc0 4y agoSure, there could be exceptions like parts of security systems that would have to be tested in production because of limitations of data/threat modeling. I'm thinking mostly end user software, UI's, games, etc. that increasingly ship things expecting to patch it along the way.