in reply to What is quality?
Unfortunately, words like "quality" aren't clearly defined, so it's easy to claim something has it - or doesn't. Indeed, as you point out, you can substitute the word "gloomf" with no significant change in the accuracy of your statement. I have a tea in my cupboard that claims to be "brisk" - who could argue?
Words like "quality", "reliability", "economic(al)", are aimed at those who make buying decisions. These decision makers often are not software professionals. They may be managers, CEO's, people in a purchasing department, etc. - they don't specialize in software, nor should they. If they're smart, they'll listen to those who do know about software. If not, they'll listen to the sales reps pushing the product, and the best sales rep wins. If your marketing department is effective, you have no need of producing "quality" software.
A prime example of this is Microsoft. Leaving aside the question of whether their software is good quality, their marketing is brilliant. They don't need to put out good software. They've got a hammerlock on the market as far as end users is concerned. They don't even have to convince decision makers that their product is the best; they've gone one step beyond that, and convinced them it's the *ONLY* product out there. They've managed to convince manufacturers to build their computers so as to thwart the use of other OS'es by using such things as the "Win-modem" - a group of chips that can function as a modem, but that requires a driver provided by Windows in order to do it. Yes, these tricks can be circumvented; the point is that manufacturers actually do it.
"Quality" - whatever that means - isn't going to ensure survival in the competitive environment of software. The perception of quality will. Good software with inadequate marketing will likely die; mediocre software with an effective marketing department will likely thrive, if the product isn't too dangerous (note that I am talking only of software sold for profit; I do not include Free or Open Source software, which survives quite nicely without sales reps).
Another issue with "quality" is again related to marketing - a mediocre product available *now* is probably going to do better than high-quality vaporware that will be out "real soon now". Those who take time to test and retest their product, to hunt down those persistent, rare, elusive bugs, are penalized. They spend more money on development, take longer to get it out the door, lower their profits, while their competitors settle for buggier code that's cheaper to make and that starts paying off right away. Those who take the high road - refuse to release a product until it has been tested and debugged thoroughly - may not survive, while those who are content to let the world be their beta testers may thrive. There's the cynical saying, "Hey, it compiled! Ship it." Unfortunately, with the marketing pressures being so intense, this is closer to the truth than we'd like to admit. I can't even say that this is a bad way to do things, within reason. No software can be proven to be bug free. Endless retesting does add to expense, and it also delays release. At some point it becomes necessary to release a product while the need for it still exists, while the price is still within reach of the target market, even if there are lingering issues. We might quibble over exactly when a release is justified, but I doubt many would insist that software must be perfect before it is released.