4 ms·

I don't agree with the article. Empathy, communication and quality are not mutually exclusive. I can empathize and sympathize with the strains of timelines, dea

I don't agree with the article. Empathy, communication and quality are not mutually exclusive. I can empathize and sympathize with the strains of timelines, deadlines and crazy demands, but that does not mean we developers and users should not push or demand quality software. This type of attitude is, in my opinion, why software quality has been going downhill over recent years. Start ups looking for the quickest buck, corporations ignoring user experience to appease crazy administrator demands. Quality should be the most talked about when it comes to software. It's not binary; it's an umbrella term to express satisfaction; it can be broken to many subcategories, true, but still can be used to express overall impression.

wambotron 11y ago
You can't really define what quality software is, though. You could have a patched together backend that "just works" and has a great UI that customers love, but how is that "quality" software? The software end of it is clunky and patched. On the other hand, you can have completely documented, easy to read, well thought-out code that has a terrible UI that no one will bother using. I guess you can say the software is "quality," but it doesn't matter. Then again, maybe "quality" software to you is software that works, like the first example. In that case, it doesn't matter how well documented it is. It works. It's self-readable at least to those who wrote it. Maybe the team will never grow beyond that, so who cares? Or by the time it does, it will be rewritten anyway for other reasons. The point, I think, the author is trying to make is that quality means so many things it means nothing. It's a useless term because it has no objective meaning. We can argue about what you think quality is and what I think it is, but it's likely going to be different for any two people.
- falsedan 11y ago
  > You could have a patched together backend that "just > works" and has a great UI that customers love, but how is > that "quality" software? The software end of it is clunky > and patched. > > On the other hand, you can have completely documented, > easy to read, well thought-out code that has a terrible > UI that no one will bother using. I guess you can say the > software is "quality," but it doesn't matter. We've been discussing what quality for our team at work, and one of the key outcomes has been recognising 'Perceived Quality' & 'Actual Quality' as distinct concepts. The main difference is, to a user, they are the same and can't be distinguished--until something goes wrong.
- nidx 11y ago
  Quality software is pretty easy to define and you described it. Quality software is software that works for everyone who uses it. That is usually a very long list - users - developers - new developers - testers/qa - designers - admins - managers - sales people - third party integration - apis - etc. You are right that most of this comes down to the iceberg problem (you only see the issues you focus on but there are many more hidden to you) The author is very foolishly thinking that communication is possible in their "solution" I can have speeches for hours with managers and sales people and have them still completely ignore quality.

wambotron 11y ago

You can't really define what quality software is, though. You could have a patched together backend that "just works" and has a great UI that customers love, but how is that "quality" software? The software end of it is clunky and patched. On the other hand, you can have completely documented, easy to read, well thought-out code that has a terrible UI that no one will bother using. I guess you can say the software is "quality," but it doesn't matter. Then again, maybe "quality" software to you is software that works, like the first example. In that case, it doesn't matter how well documented it is. It works. It's self-readable at least to those who wrote it. Maybe the team will never grow beyond that, so who cares? Or by the time it does, it will be rewritten anyway for other reasons. The point, I think, the author is trying to make is that quality means so many things it means nothing. It's a useless term because it has no objective meaning. We can argue about what you think quality is and what I think it is, but it's likely going to be different for any two people.

falsedan 11y ago
> You could have a patched together backend that "just > works" and has a great UI that customers love, but how is > that "quality" software? The software end of it is clunky > and patched. > > On the other hand, you can have completely documented, > easy to read, well thought-out code that has a terrible > UI that no one will bother using. I guess you can say the > software is "quality," but it doesn't matter. We've been discussing what quality for our team at work, and one of the key outcomes has been recognising 'Perceived Quality' & 'Actual Quality' as distinct concepts. The main difference is, to a user, they are the same and can't be distinguished--until something goes wrong.
nidx 11y ago
Quality software is pretty easy to define and you described it. Quality software is software that works for everyone who uses it. That is usually a very long list - users - developers - new developers - testers/qa - designers - admins - managers - sales people - third party integration - apis - etc. You are right that most of this comes down to the iceberg problem (you only see the issues you focus on but there are many more hidden to you) The author is very foolishly thinking that communication is possible in their "solution" I can have speeches for hours with managers and sales people and have them still completely ignore quality.