It's all the extras that make a better version of the same product that's missing.
I think you're seeking "fit for use" = quality, instead. This is closer to the parent comment.
Adding extra things is necessarily exceeding specifications.
If the spec calls for a car, and I give you a car with a roof-rack, then I've exceeded the specification for what the car must do. Whether that's an improvement is subjective. If you don't need the rack, then your MPG suffers.
Quality in the informal sense that is used in every day talk is how well a product/service fulfill the expectations of it's kind.
Which means that a bad chair and a good chair can both be of perfect quality if they do not deviate from the specifications. If there are no specifications the quality is unknown.
Formal usage of quality can be measured, informal cannot.
When I think of "quality" in an informal sense, that's not what I think. I've got a cheap keyboard + mouse combo. They work perfectly well for what I use them for, but (I suspect) for less time, and enduring less abuse, than a higher-quality set of input devices would. I consider them low-quality, but suited-to-purpose. Something can be low-quality, but sufficient (i.e. fulfill my expectations, but be below the minimum specification level for what I'd call "quality").
edit: Although, I suppose that I'm talking more about my objective perception of quality than anything else.
Aka, To be a low quality chair something must first be a Chair. A decomposed Apple is dirt not a low quality Apple.
You can't exceed "1m exactly", but that's the same as saying you can't exceed perfection. The specification is not perfection, the specification is "1cm slop". You can exceed it.
In other words it's not the distance to the edge of acceptance that's important it's the distance from perfection as long as it's fit for use.
Take any method to determine the closeness of a cut to ideal. That method also describes how much a cut exceeds minimum spec.
Which if you look at my original post, that's the wording I used.
* Looks good
* Comfortable
Quality isn’t conceptually hard. It’s the result of thoughtfulness, care, and dilligence. Three seemingly unwelcome qualities in a lot in software development settings. Any attempt to codify what quality is beyond that will dimish the significance of those pre-requisits and embolden those that don’t possess them.
Quality is also the first thing you sacrifice when you offshore your development, and that’s something no ones wants to talk about. That’s not to say offshore teams are incapable of achieving quality. It’s to say that the rules of offshoring incentivise against quality and guarantee that your flawed specifications and requirements will be met with brutal efficiency and go unquestioned.
Its easy for Tesla to say ok if we spend X Million on this machine tool which can work to 10 Thou rather than 20 Thou it will reduce our wastage rate for widget Z by Y% there for the payback period is so many months - classic production engineering 101.
Because quality is often subjective, I'll be shocked if you can provide a generalized definition.
> One of Phaedrus' realizations was that quality is neither subjective (depending on the judge) nor objective (an objective fact, like the mass of a book in kilograms).
Sounds like a contradiction in terms, like a binary value that's neither true nor false. Unless the conclusion was that quality is a composite of some objective properties and some subjective ones.
How “well” something fits is absolutely subjective. It’s a judgement call with no objective measure.
I was picturing a requirements list of numerical ranges, which a specific unit of a product must satisfy. "How well" is what came to mind when I pictured a unit that nearly exceeded the limits of its requirements, compared to a unit that sat perfectly in the middle of the range of every requirement.
I never pictured any kind of "judgement call", and I'd hoped that would be clear, in the context that I'd set, talking about objective measurements of quality.
The example from early on is about how Pirsig sees a beer can as a perfect shim for motorcycle handlebars because it meets the specifications of what's needed for the job (classical quality) while his friend isn't sure because it doesn't feel right to put a beer can into a BMW motorcycle (subjective quality).
The book's resolution of this dilemma is kind of hazy to me (something about cleaving a marble in half while reaching the top of a mountain?) but I think it's about how these are individually insufficient ways to define quality and you need both.
I suppose the software version of this is like: passing tests don't imply that anybody is going to want the thing you've made.