4 ms·

Note that I was answering to a list of measurements software developers could make. You seem to argue on the topic of reliability. I have fewer things to say ag

by jraph 2y ago

Note that I was answering to a list of measurements software developers could make. You seem to argue on the topic of reliability. I have fewer things to say against this. The software equivalent of your car not exploding or your stuff falling down would be the bugs. You don't usually avoid bugs by measuring stuff, you avoid them through robust processes (including testing). I assume that's also the case for avoiding engineered things to collapse. Now, software does often improve people's lives despite the bugs, and most bugs are not life threatening. Less reliability in software compared to many engineered stuff for cheaper production is apparently a common (and most certainly reasonable) tradeoff we are willing to make. That's not the case for software involved in critical stuff usually btw. We haven't gotten to that level of reliability in software in general, and we probably never will, because in most cases, it's not worth the cost. It's likely not a question of rigor or maturity of the field: the human species knows how to produce reliable software when it decides it's worth the cost.

_aavaa_ 2y ago
> Note that I was answering to a list of measurements software developers could make. You seem to argue on the topic of reliability. Those are not distinct categories. I was making the point that many of the things you mentioned referred to how well they improve the lives of users. These things are analogous to ergonomics, comfort, aesthetic requirements for many objects. I'm saying that those concerns come after you have built something that does not fail often. > and most bugs are not life threatening. Neither are most physical defects in many products, but they are still taken care of before being pushed out the door. Tesla may wish to use its users as paid beta testers, but most automakers actually test their stuff before selling it. > Less reliability in software compared to many engineered stuff for cheaper production is apparently a common (and most certainly reasonable) tradeoff we are willing to make. This is a tradeoff made by the companies, not be the people using it. I am forced to use Teams at work regardless of how shitty a piece of software it is. Most software companies simply don't have the kind of competition required to require them to make good software. Why spend engineering dollars on improving teams when you can bundle it and have employers force it on their employees.

by jraph 2y ago

_aavaa_ 2y ago

> Note that I was answering to a list of measurements software developers could make. You seem to argue on the topic of reliability. Those are not distinct categories. I was making the point that many of the things you mentioned referred to how well they improve the lives of users. These things are analogous to ergonomics, comfort, aesthetic requirements for many objects. I'm saying that those concerns come after you have built something that does not fail often. > and most bugs are not life threatening. Neither are most physical defects in many products, but they are still taken care of before being pushed out the door. Tesla may wish to use its users as paid beta testers, but most automakers actually test their stuff before selling it. > Less reliability in software compared to many engineered stuff for cheaper production is apparently a common (and most certainly reasonable) tradeoff we are willing to make. This is a tradeoff made by the companies, not be the people using it. I am forced to use Teams at work regardless of how shitty a piece of software it is. Most software companies simply don't have the kind of competition required to require them to make good software. Why spend engineering dollars on improving teams when you can bundle it and have employers force it on their employees.