Software Product Quality

What is the quality of a software product and how to measure it?
I've worked in several software companies where quality of the products was constantly problematic, and no matter how much each of these companies tried to improve the quality of its products, the quality stayed basically unchanged. Pretty much everyone agreed that the company's product quality was pretty low, but if you asked five people that worked on improving quality of company's product what quality actually was, you'd get five very different answers. IMHO, this is indicative of the root problem that plagued these companies: the management never took the effort to clarify what quality of their products was, so when they tried to get their employees to improve it, the efforts were anything but aligned, and thus failed miserably.
When you think about it, it is quite indicative that after more than 50 years of its existence, software industry hasn't come up with a definition of software product quality that every future software engineer would learn in the very first year of her undergraduate studies. If there were such definition, the companies mentioned above would be facing quite different problems, most likely not related to quality.
In my experience, quality of a software product is no different from the quality of any other product. Wikipedia gives more than a few definitions, but here I'll offer my definition:

Quality of a product is its ability to meet the needs and expectations of its users.

Quite simple, isn't it? Well, maybe not, but here are some implications of this definition:

• Quality is in the eye of the user, and not product tester, manager, developer, or any other person responsible for providing the product. Hence it is inherently subjective, which further means that the same product will be viewed as having different quality by different users. A perfect place to witness this on-line are reviews of mobile applications.
• The quality of a product is a function of not only how it satisfies the needs of the user, but also of its users' expectations, which are product of multiple factors, including marketing of a product, product's price and many more. For example, user's expectations from a freeware software application are typically lower than from a commercial software application with a hefty price tag. Also, expectations from a product claiming to be the best-of-breed are higher than from a product not making any such claims.
• Different products that a single organization produces and/or sells may be perceived as of different quality. Common brand does typically set some common user's expectations, and both positive and negative experiences of different products marketed under that brand can have influence on user's perception of quality of other products under the same brand, but the quality of each product is fundamentally individual.
• Any change in the product can cause quality to change, so each product version has its own quality.
• Because the needs and expectations of its users change over time, the quality of a product is a function of time, even if the product itself doesn't change at all.
• A poorly designed and/or implemented feature that doesn't solve any particular user's need, but also does not stand in the way of other features that do solve user's real needs and meet their expectations may not necessarily be perceived as low product quality, as users will simply ignore it.

Now that we have a working definition of software product's quality, how do we measure it? Well, this is where things get just a bit more complicated. All too often, people will measure something only because they can, not because it's useful. This topic inevitably brings me the memory of a certain vice president that opened a software product release party by emphasizing the fact that this particular release of this software product involved fixing more than 15 000 defects! He didn't bother to elaborate on this fact, so I can only guess that he thought this fairly large number had something to do with presumably high quality of that release. If he thought twice about it, however, he'd probably have realized that this fact also meant that software developers in this organization managed to create all of these 15 000 defects that were claimed to be fixed, just like the undisclosed number of defects that were left for users of this release to discover. It almost goes without saying that the release in question had just as low quality as any of its predecessors. Thus, disclosure of this "quality metric" spoke much more about the person which quoted it, than about the quality of the related software product.
If counting fixed defects is not a particularly good measure of a software product's quality, then what is?
Before answering this question, we have to answer another question first: why would we want to measure quality at the first place?
All too often, software development management of different levels will start collecting metrics before answering this simple why question, which then leads to "celebrations" like the one mentioned above. My answer would be: it makes sense to put an effort in measuring quality only if you're willing to make changes to your software development processes when the quality turns out to be lower than desired. There's absolutely no point in measuring status quo. The benefit of measuring in the presence of changes is to be able to discern positive from negative and neutral changes. Unfortunately, there's no single recipe for improving software product quality, (although specification by example seems to work quite well, at least based on experiences described in Gojko Adzic's excellent book on that subject.
Only once we're sure we indeed do need to measure quality, and have a good idea what we're going to do with the results of such measurement, should we try to answer the how question.
The answer depends on the software product and the context of its usage. In case of a mobile application for Android operating system, for example, the user's ratings may be the ultimate measure - they almost perfectly match the definition of quality given above. And since Google has already provided the measurement tool, the cost of measurement is virtually zero for the company producing the application (although there's still some effort required from the users, so it's probably a good idea to incorporate into the app a reminder/enticement for app's users to rate the app).
For software products that don't have such readily available user rating system, one option is to perform regular user satisfaction surveys. This was approach taken by Siebel Systems, Inc. It worked pretty well, except that management had vested interest in getting these surveys as positive as possible, because they were used for marketing, not just as internal tools. This caused less-than-realistic results, which kept the company in a semi-delusional state, until the hard reality of slow sales caused the CEO and founder, Tom Siebel to step down, eventually leading to company's acquisition by Oracle. The morale is: if you're going to invest significant resources into getting user feedback, make sure that feedback is realistic, otherwise it's actually counter-productive.
It's always a good idea to only measure what you care about. In pretty much every of the companies struggling with quality, I've seen a high rate of software patching. This can be simply explained by the hypothesis that a company that ships low quality software products and does not patch them would very soon face bankruptcy. It's almost as if the ability of software products to be patched was interpreted by these companies as a license to ship software products of (mildly put) questionable quality.
Unfortunately, regardless of the technology used, patching of a software product is never cheap. There's always engineering costs related to patching, which exponentially rise as the time-sensitivity of the patches increases. For example, if you promise to fix every critical defect within 24 hours, your engineers will need to be available over weekends. If you promise to fix it within 12 hours, your engineers will need to be available 24/7. And if the amount of patches is high, this puts extreme stress on your engineers, which, if persistent, will drive them away, and your organization will have to incur significant cost of replacing them.
So, if the amount of patching is important for an organization, then, a good measure of quality is average days between patches caused by customer escalations. So, if a product A has had 120 patches in last 30 days, and product B only 10 in the same time period, then quality of product A is 0.25 [days between patches], while quality of product B is 3 [days between patches].
What are your experiences with software product quality? Do they resemble mine? I'd love to read about them in the comments section!