"Beauty is Truth, Truth Beauty" from Keats or Pirsig's concept that we know quality when we see it, because it is beautiful is probably about the best definition we will get beyond "fitness for purpose"
It boils down to the ever swinging pendulum between function and "face value". Bauhaus and Jugendstil.
I have had this discussion many times with people (colleagues). It can look nice, but hard to use or apply. Even code can look pretty, but hard to implement or integrate.
Function should always be the first and foremost thing to focus on. Period. Nobody in any field of engineering ever starts a project properly based on how things should look. Constructing buildings without taking into account on how it should be used should not be common place anywhere. Not even in China. Where I've seen many examples of bad practice. Focusing first on appearance and artistic appeal is very dangerous.
So, "better" falls in this category of "function", "applicability" and a lot of other *ilities. Quality on the other hand is enforcing it, making it more robust, maintainable, clearer. Often by making it more simple and generic. Abstracting away where possible without losing sight of how easy it is to keep it adaptable to change. Read "Righting Software" the first five chapters to get a gist of this.
So, yes. Higher quality can make it better. But only after function is created, corrected and approved. I can use a fine high quality fork to eat. But not with soup. While a plastic or even paper spoon does the job just fine.
Is not Software Quality an abstraction like any other? So it can be defined but needs specific constraints to make it concrete. The “who” you mentioned is a useful one. Personally I like Fowler’s breakdown of internal vs external quality, because it decouples the two concerns.
"Beauty is Truth, Truth Beauty" from Keats or Pirsig's concept that we know quality when we see it, because it is beautiful is probably about the best definition we will get beyond "fitness for purpose"
I like “better” because it gives me concrete questions to ask and tasks to do.
It boils down to the ever swinging pendulum between function and "face value". Bauhaus and Jugendstil.
I have had this discussion many times with people (colleagues). It can look nice, but hard to use or apply. Even code can look pretty, but hard to implement or integrate.
Function should always be the first and foremost thing to focus on. Period. Nobody in any field of engineering ever starts a project properly based on how things should look. Constructing buildings without taking into account on how it should be used should not be common place anywhere. Not even in China. Where I've seen many examples of bad practice. Focusing first on appearance and artistic appeal is very dangerous.
So, "better" falls in this category of "function", "applicability" and a lot of other *ilities. Quality on the other hand is enforcing it, making it more robust, maintainable, clearer. Often by making it more simple and generic. Abstracting away where possible without losing sight of how easy it is to keep it adaptable to change. Read "Righting Software" the first five chapters to get a gist of this.
So, yes. Higher quality can make it better. But only after function is created, corrected and approved. I can use a fine high quality fork to eat. But not with soup. While a plastic or even paper spoon does the job just fine.
Is not Software Quality an abstraction like any other? So it can be defined but needs specific constraints to make it concrete. The “who” you mentioned is a useful one. Personally I like Fowler’s breakdown of internal vs external quality, because it decouples the two concerns.
Internal/external answers the “for whom” question. I think we can find even finer-grained questions.