Software Engineering, Project Management, and Effectiveness
“Quality begins on the inside... then works its way out.” -- Bob Moawad
Quality is value to someone.
Quality is relative.
Quality does not exist in a non-human vacuum.
Who is the person behind a statement about quality?
Who’s requirements count the most?
What are people willing to pay or do to have their requirements met?
Quality can be elusive if you don’t know how to find it, or you don’t know where to look. Worse, even when you know where to look, you need to know how to manage the diversity of conflicting views.
On a good note, Agile practices and an Agile approach can help you surface and tackle quality in a tractable and pragmatic way.
In the book Agile Impressions, by “the grandfather of Agile Programming”, Jerry Weinberg shares insights and lessons learned around the relativity of quality and how to make decisions about quality more explicit and transparent.
Here are some conflicting ideas about what constitutes software quality, according to Weinberg:
“Zero defects is high quality.” “Lots of features is high quality.” Elegant coding is high quality.” “High performance is high quality.” ”Low development cost is high quality.” “Rapid development is high quality.” “User-friendliness is high quality.”
There are always trade-offs. It can be a game of robbing Peter to pay Paul.
Via Agile Impressions:
“Recognizing the relativity of quality often resolves the semantic dilemma. This is a monumental contribution, but it still does not resolve the political dilemma: More quality for one person may mean less quality for another.”
“The reason for my dilemma lies in the relativity of quality. As the MiniCozy story crisply illustrates, what is adequate quality to one person may be inadequate quality to another.”
“If you examine various definitions of quality, you will always find this relativity. You may have to examine with care, though, for the relativity is often hidden, or at best, implicit.
In short, quality does not exist in a non-human vacuum, but every statement about quality is a statement about some person(s). That statement may be explicit or implicit. Most often, the “who” is implicit, and statements about quality sound like something Moses brought down from Mount Sinai on a stone tablet. That’s why so many discussions of software quality are unproductive: It’s my stone tablet versus your Golden Calf.”
The way to have more productive conversations about quality is to find out who is the person behind a specific statement about quality.
“When we encompass the relativity of quality, we have a tool to make those discussions more fruitful. Each time somebody asserts a definition of software quality, we simply ask, “Who is the person behind that statement about quality.”
Whose requirements count the most?
“The political/emotional dimension of quality is made evident by a somewhat different definition of quality. The idea of ‘requirements’ is a bit too innocent to be useful in this early stage, because it says nothing about whose requirements count the most. A more workable definition would be this:
‘Quality is value to some person.’
By ‘value,’ I mean, ‘What are people willing to pay (do) to have their requirements met.’ Suppose, for instance, that Terra were not my niece, but the niece of the president of the MiniCozy Software Company. Knowing MiniCozy’s president’s reputation for impulsive emotional action, the project manager might have defined “quality” of the word processor differently. In that case, Terra’s opinion would have been given high weight in the decision about which faults to repair.”
Quality is a human thing.
“In short, the definition of ‘quality’ is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another. Of course, much of the time these political/emotional decisions– like all important political/emotional decisions–are hidden from public view. Most of us software people like to appear rational. That’s why very few people appreciate the impact of this definition of quality on the Agile approaches.”
Open processes and transparency can help arrive at a better quality bar.
“What makes our task even more difficult is that most of the time these decisions are hidden even from the conscious minds of the persons who make them. That’s why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness. And that’s why development teams working with an open process (like Agile) are more likely to arrive at a more sensible definition of quality than one developer working alone. To me, I don’t consider Agile any team with even one secret component.”
The quality of your product will be gated by the quality of your representation.
“Customer support is another emphasis in Agile processes, and this definition of quality guides the selection of the ‘customers.’ To put it succinctly, the ‘ customer’ must actively represent all of the significant definitions of ‘quality.’ Any missing component of quality may very likely lead to a product that’s deficient in that aspect of quality.”
It’s faster and far more efficient to ignore people and get your software done. But it’s far less effective. Your amplify your effectiveness for addressing quality by involving the right people, in the right way, at the right time. That’s how you change your quality game.
“As a consultant to supposedly Agile teams, I always examine whether or not they have active participation of a suitable representation of diverse views of their product’s quality. If they tell me, “We can be more agile if we don’t have to bother satisfying so many people, then they may indeed by agile, but they’re definitely not Agile.”
I’ve learned a lot about quality over the years. Many of Jerry Weinberg’s observations and insights match what I’ve experienced across various projects, products, and efforts. The most important thing I’ve learned is how much value is in the eye of the beholder and the stakeholder and that quality is something that you directly impact by having the right views involved throughout the process.
Quality is not something you can bolt on or something that you can patch.
While you can certainly improve things, so much of quality starts up front with vision and views of the end in mind.
You might even say that quality is a learning process of realizing the end in mind.
For me, quality is a process of vision + rapid learning loops to iterate my way through the jungle of conflicting and competing views and viewpoints, while brining people along the journey.
Quality can be simply defined as “fitness for use”, definition that includes directly or indirectly aspects like value, relativeness, elusiveness, performance, friendliness, perception, features, etc.
Most of the above short statements don’t define quality, but give some coordinates for evaluating quality. The use of “is” is more a context-dependent figure of speech.
Some years ago I prospected quality’s definition from the point of view of data: sql-troubles.blogspot.de/.../data-quality-introduction.html
@Adrian -- That's a pretty good definition.
> Most of the above short statements don’t define quality, but give some coordinates for evaluating quality.
That was Jerry Weinberg's point.
Regardless of how you define it, the challenge remains:
Quality is relative, there are multiple view-points, multiple values, and it's always a human thing. And it's the prioritizing and balancing and trade-offs that are the hard part.
So while some folks have tried to make quality definitive, absolute, and people-independent -- something you can define and be done with -- the advantage that Agile has is embracing the people part, making the decisions explicit and transparent, and providing pragmatic ways to make quality part of the journey vs. a separate and discreet effort, or a one-time deal.