4 ms·

The line of when it's ready to be used is not clear and I think it has been pushed forward such that the user increasingly becomes the tester. This is unaccepta

by proc0 4y ago

The line of when it's ready to be used is not clear and I think it has been pushed forward such that the user increasingly becomes the tester. This is unacceptable in hardware products, imagine if kitchen appliances were sold with issues, and you had to take it back to the store for fixes and updates. Unfortunately, users don't know any better, and I think that's why so much of the industry gets away with serving them a bad user experience that is bad because in essence you are testing it.

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 ago
  How does this line of thinking address security?
- bbjJqJmxFNbAcg9 4y ago
  That'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 ago
  Sure, 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.

by proc0 4y ago

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 ago
How does this line of thinking address security?
bbjJqJmxFNbAcg9 4y ago
That'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 ago
Sure, 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.