I have a book on quality (I forget the title) that pointed out the fact that while everyone talks about quality, it is rarely defined. The book went on to define quality thusly: "Quality is the ability to meet a specification" (that's my rephrasing as I can't find the book).
Quality is the degree to which something exceeds minimum specifications. You can sit on a low quality chair etc. You can enjoy a low quality meal. A low quality car still moves you from A to B.
It's all the extras that make a better version of the same product that's missing.
Quality in the formal sense should not exceed specifications. It should meet them and every point where specifications are not met is considered a defect.
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.
It's not exceeding specifications because maximum specifications are undefined. Supose you want a 1 meter +/- 1 cm long wooden board, a board can only get closer to exactly 1m, but it's meaningless to suggest it can exceed that specification. On the other hand you can get close to the edge of acceptance at 1meter +/- 0.9999 cm.
Aka, To be a low quality chair something must first be a Chair. A decomposed Apple is dirt not a low quality Apple.
A board 1cm off meets the specifications. A board .2cm off exceeds the specifications in terms of precision. The closer to a perfect meter, the more it exceeds the minimum.
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.
You're assuming the ideal item must sit at the midpoint of the specification. The ideal may be at 1m 0.1cm, but there is better tolerance for short boards than long ones.
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.
Oh, that post was you also... Then I was just very confused by the first post I replied to, and thought you were saying the opposite of your point with "it's not exceeding specifications".
> 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.
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.
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.
Grr. I’m sick and tired of rubbish specifications, poorly defined acceptance criteria, and the code that meets it. If you put shit in, you’re going to get shit out. Quality is what seperates the shit from the good. If no one on your team knows what quality looks like, or worse, they like the smell of shit, you’re getting shit, and everyone is going to pat themselves on the back like it’s a job well done.
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.
I once worked at a big electronics company at the time when TQM (Total Quality Management) was the buzzword. Senior management was on the band wagon and regularly kept dropping TQM initiatives that distracted us from doing our jobs. Once they sent around a survey that asked us to define "Quality". While most of us tried to avoid completing the survey, one of my coworkers took the time to carefully answer that question. He said that "Quality is doing such a good job that nobody will ever again ask you to define what quality means."
I think that's the formal production engineering definition -the trouble comes when you apply it to the messy world of software.
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.
I think the definition implicitly described in that book is "Quality is the ability to satisfy the innately messy human value function". Which I think is a pretty okay definition. Though it's a better definition for beauty.
It's been a while since I read it, but my takeaway was that there's a kind of tension or dilemma between classical quality and subjective 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.
Perception of quality is subjective. An objective measurement of quality would be how well something fits a set of requirements. Something fitting that definition of "quality" could still be perceived as low-quality, of course, but I think that's a different question.
That's _not_ what the book concluded. 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).
I never said that it was. I've never read Zen and the Art of Motorcycle Maintenance. The previous comment asked for a definition of quality. I provided one that made sense to me.
> 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.
I think that you read my comment in a way that I didn't intend. "How well" would probably be better phrased as "whether", because "how well" implies a non-binary state.
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.
I think the important part of this is that all three circles in their Venn diagram must intersect. If they don't, you'll fail. Either because the production quality is non-existent, no business value is being added, or the product doesn't have the right attributes to be saleable.
How big does this sweet spot intersection need to be? "As large as possible" doesn't sound right - because it says you've spent too much time polishing and not enough time getting it in front of customers. Too small and your value isn't obvious enough, inviting the competition to steal your lunch. So .. perhaps it should be "just right", whatever that means for your market.
The author says these are Venn diagrams, but he omits saying what the domain is. Are the members of these sets programs? If so, then he is saying that a program may have any combination (including possibly none) of these three concepts of quality, but a given program (or whatever the elements are) either possesses a given quality, or it does not - the model, as presented, does not allow for degrees of quality. In this interpretation, as large as possible a sweet spot would simply mean that you have many programs having all three qualities, and if that is not optimal, then the model is not complete.
To be clear, I don't think this is what the author meant; I suspect either I have guessed wrongly about the set's domains, or he has just chosen a flawed way of expressing himself.
there is one important aspect of "quality" that leads to all other: quality is achieved at global maximum. A lot of engineering methodology is focused finding a local maximum.
Unfortunately, for even highly simplified idealised problem spaces of only moderate complexity, the best algorithm would take longer than the life of the universe to find the global maximum. Worse, for most of them, even if I gave you the global maximum solution, it would take you longer than the life of the universe to verify that.
Or, put another way, actually producing something before the heat-death of the universe is, imho, a prerequisite for quality.
(FYI: Passed over "Jobs' Jib", though it really does seem to shortcut the average serenade of the Steve Jobs worshipper with a concise and clear, engineer-comprehensible explanation of his management style! Hehehe.)
It's design or management thinking versus nuts and bolts engineering. Even if it seems superfluous for a given problem, it has value in generality (eg. broadly applicable to complex project management/planning) and optimization (eg. prioritization of development effort/resource allocation against perceived customer experience impact) at macro level.
Why not just go for an ISO standard definition, like 9000 or 9001? It means to meet specifications. Specifications specify sold gold and it is solid, then it is quality. If it is gold plate then it is not.
