As soon as I started talking about “better” software, I got a flood of definitions of quality, each seeming to advance some agenda of the definer. (To be sure, I have my own agendas.) I’m going to take a crack here at what I mean by “quality”.
With my recently gained understanding of power differentials, the first question is, quality to whom? Software serves many communities. Better for one community may mean worse for another. We have:
Programmers
Designers
Product managers
Data scientists
Operators
Users
Purchasers
Trainers
Investors
Managers
Sponsors
Marketers
Sellers
Even for a single community, two definitions of Better can conflict. For programmers, what’s better software for this current change may be worse software for future changes. (Tidy First? aims to reduce this conflict by making things a little better between changes.)
Between communities, the conflicts intensify. We can’t ever say “better” full stop.
My career is built on programmers writing software that is better for them in ways that align well with being better for the business. It’s an inherently selfish position. I want to work with good code & I want someone to keep paying for me to work with good code. Some of the folks on the list above will be well served by this strategy, others will be asked to adapt. If the adaptation stretches them too far, the whole thing falls apart. We’re in a boat, rowing together, & we cross the finish line together or not at all.
Define “quality”? Oh hell no. Not stepping into that. I know what better looks like for programmers like me. I’ll keep encouraging that & looking for connections to other communities.
"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.