Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

What is quality?

by jimt (Chaplain)
on Jul 27, 2006 at 17:43 UTC ( [id://564190]=perlmeditation: print w/replies, xml ) Need Help??

I'm very very guilty of this myself, so while I am getting up on my high horse, I am by no means an innocent. It's also in no way perl specific, though I am going to focus on software in general, largely since I haven't a clue how to identify a high quality wine or batch of cement.

In my reading and working and perusing of things I see a lot of attention being paid to "quality" of the software.

  • "We write high quality software."
  • "Our software is of the highest quality."
  • "This is the best quality wine you can buy."
  • "Our product quality is unsurpassed."

But what the hell does that mean and how do you prove it? Think fast now - you march around telling the world that your software is top notch quality. You're an awesome programmer and you write the best stuff. And my response? "Prove it."

If you're lucky, you can point to your comprehensive test suite. You've written thousands of tests and it exercises every point in your code. Both values for every conditional, every while loop, every function/module/class/you name it. It's created/modified/set/unset/deallocated and it all goes off clean as a whistle.

You produce your impressive Devel::Cover charts and graphs and have green 100%s across the board. Everything's documented, everything's tested, everything works (at least, as far as your test cases are concerned). You have demonstrated that your software is high quality.

Haven't you?

Well, you're off to a good start. You can demonstrate that your software pretty reasonably behaves with a huge amount of sample input. Basically, that it works. Sure, there's always the case that the user types in something that you really weren't expecting and things go haywire, but you should've handled enough cases to be reasonably sure you're fine. You've quantified the quality of your software.

Have you? Microsoft's software normally works, but I tend to consider it low quality.

If you don't have a test suite, then my suspicion of your software will grow with its size. No test suite and a 100 line program? Yeah, it's reasonable to assume that it works fine (assuming your reputation is good enough) and that you tested and caught the bugs. No test suite and a 100 module program? I'm a little more dubious that you've caught ever possible option. It's also easy to assume that you can introduce bugs as things get worked on.

You stomp your little feet and scream that it's good quality and I shrug and again ask you to prove it.

So then you start showing me pieces of the code. Carefully handcrafted and elegant and efficient in what they do (you claim). Sure, this can demonstrate the quality of your work, but only to another skilled craftsman. And, frankly, when it comes to software, another skilled craftsman is probably going to want to at least know that there is a reasonable test suite, even if he's not inspecting it.

But let's assume we're past the test suite. Now what? Let's break it down into 4 simple cases.

  1. You have good quality software and I can recognize it as good.

    Congratulations! You win. You demonstrate your fine craftsmanship to me, I immediately recognize you as one of the great masters and at a minimum continue to evaluate your software, if not outright choose it.

    For this approach to work, you not only have to be truly capable of producing great work, but you need to find someone capable of recognizing it. It can work, but if this is the way you demonstrate quality, you've greatly reduced your market. A Rolls Royce may be hand-crafted elegance and worthy of the cost, but most of the public probably doesn't know why. They needed some other authority to tell them it's better, an expert in the material.

  2. You have good quality software and I can't recognize it as good.

    You're hosed. You can't quantify your quality, and I (for whatever reason) can't recognize it. Sure, it's possible that you'll convince me that you're right and I'm wrong and it's really good software, but I've probably already made up my mind. I'll go off to choose a different product that I think is higher quality (maybe they have a full test suite), regardless of whether it actually is or not.

  3. You have poor quality software and I can recognize it as poor.

    You're hosed. Despite all of your stomping and hooting and folderol I know you're full of baloney and you've lost my business. With no test suite, you can't demonstrate that it actually works, so you're relying upon my looking at your software and assuming that it must work, based upon what I've seen. But it looks crummy, so I'm going to assume it doesn't work. On to the next product.

  4. You have poor quality software and I cannot recognize it as poor.

    This is a very dangerous place to be in. You'll present shit and I'll call it shinola and buy 1,000 gross of it and I'm off to the races. Later I may or may not realize that there are problems and may or may not complain about it. You may keep my business, you may not.

    But you're targetting people that don't know any better. Don't get me wrong, there's a large audience out there, but it's an ever dwindling one. It's relatively easy to get smart and relatively hard to get stupid. Once you've learned that you don't put your hand into a campfire, you rarely forget and start doing it again.

    So you're basically hoping that I never begin to think that your software is low quality (and, remember, for this example we're assuming it is), because once I make the connection, I'm off to another vendor. Admittedly, they may also be poor quality (again, in this example I'm a poor judge), but the point is it's no longer you I'm doing business with.

In 1 out of the 4 cases, you're fine. In 2 you're boned from the getgo. In 1 you're probably boned in the future. That's a 75% failure rate, but you actually had good quality software 50% of the time. Your good stuff will fail in the marketplace more often than it will succeed, even if it's good "quality" (which you can't quantifiably demonstrate.

Now what? Well, you can go back to your software and write up a comprehensive test suite and probably find a few bugs in the process and quash them. Then you've got your test suite and you can quantify your quality. But the underlying code may still be junk, just very functional junk. So, I ask you, is that high quality software or not?

The case can be made that "good quality" software only need a few elements.

  • Demonstrably does what it's supposed to do.
  • Is "easy" to maintain and develop. ("easy", of course, is a relative term)

And then what more do you need? You can prove your software works to the Doubting Thomas, and he can even look at your code and understand it after the fact (if need be). More importantly, the next developer you hire can look at it and understand it. Since your software is high quality, hopefully you'll only hire other progarammers who product high quality software and can also recognize high quality software. And everyone is happy.

But I still don't feel like this is enough. Every time I hear the word, I picture Dilbert's boss saying, "And we'll get a big banner that says 'quality'." It's a meaningless, undefinable, useless word that everyone tosses about like it's the holy grail. But when pressed on the issue, they can't explain why their software is high quality. Just because it took a long time to complete doesn't mean that it's any good. I could take a long long time building a new automobile and it'd still suck.

Isn't it silly to claim that your software is something that you can't even define or demonstrate? How do you know that your software is very high quality? You might as well start saying that your software is all very gloomf. I think that's what I'll do.

Replies are listed 'Best First'.
Re: What is quality?
by wfsp (Abbot) on Jul 27, 2006 at 18:31 UTC
    As a technical term quality is not a description but the concept of meeting the specification. Outside of the comparison with the spec it is meaningless. High or low quality more so.

    Describing the spec you can/do work to will give a more accurate idea of what can be expected and be more useful to a potential customer than lofty, vacuous phrases. A high or stringent spec is the business.

    I was an aero-engine Quality Engineer for 24 years and slept through many presentions of consulants brought in to describe/reorganise quality. The name got changed a few times, Quality Assurance, Product Assurance and back to Quality. And back to the simple fact that:

    "It's the spec, stupid!"

    I remember my boss ransacking the reference library for a definition of chrome. It included the phrase "beautiful sheen". Sadly, that never made it to the Quality Manual.

Re: What is quality?
by Albannach (Monsignor) on Jul 27, 2006 at 19:43 UTC
    You seem to be equating "highest quality" with "best", which is unfortunately not how the world works. To echo wfsp, the highest possible quality would mean meeting the specification perfectly. This is of course not necessarily the "best" product depending on your view however, for example:
    • the spec itself may be slightly or deeply flawed, and then even a perfect quality product ends up failing in operation as a result;
    • the spec may not foresee future needs, and the resulting product could be fine initially but hit some portability/scalability/expansion barrier in the future that could have been avoided by better initial design;
    • to meet all users needs, strictly speaking you'd really have to interview them all, but that's not often going to happen, so inevitably some will not be happy with the result, even if it meets the spec;
    • the "best" solution may include characteristics not explicitly called for in the spec, and hence will cost more, so a competitor will get the contract;

    In all these cases, the product would be subject to significant criticism and likely not often considered to be high quality, yet in all cases the product could be of highest quality. Does anyone have access to Microsoft's internal specs for Excel? Maybe it's already better than it was intended to be!

    I'm sure others have gone through the "Total Quality Management" era (translation = don't give the client any more effort than they paid for), and now we're in the ISO9000++ era (translation = be able to describe exactly what you did). Do these result in better products? More consistent perhaps, but not better in my opinion.

    I'd like to be able to assign to an luser

Re: What is quality?
by swampyankee (Parson) on Jul 27, 2006 at 21:53 UTC

    Like wfsp, I worked in aerospace (in engine test, structural test, and later aerodynamics). Unlike the vast bulk of software failures, which are annoying, embarrasing, or, at worst, expensive, aerospace failures have a disturbing tendency to be lethal.

    Quality isn't a thing, so much as a process. And it's not something that can be added after the fact, or by inspections, or by testing.

    Inspection (in the software world, code audits, code walkthroughs, etc) are one part; testing is another (and everybody here knows that coming up with realistic test cases is difficult). How to deal with defective components is another part (as an example, the famous Pentium floating point error). Specifications are very important. Manuals for users, documentation for maintenance, procedures for future upgrades, etc, are all part of the quality process.


    Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read.

    Groucho Marx
Re: What is quality?
by eyepopslikeamosquito (Archbishop) on Jul 28, 2006 at 02:31 UTC

    Quality should be considered from different perspectives:

    • Customer perspective.
    • Developer perspective.
    • Support Analyst perspective.
    • Sales and Marketing perspective.
    You need to find a balance between these different views of quality before releasing a product.

    How much time and money you spend on quality and testing depends essentially on economics. When failure is unthinkable, you spend a lot more. For example:

Re: What is quality?
by sfink (Deacon) on Jul 28, 2006 at 06:38 UTC
    None of those phrases you started out with have anything to do with quality, code or otherwise. They're merely marketing gibberish that may as well be "we're gooder more good bester than everyone else!"

    It's meaningless. But what would you have them say? "Although our software may not be the highest quality out there, it costs less and still gets the job done"? Not gonna make many sales that way. Any company that sells a software product is either going to (1) claim it's high quality; or (2) not talk about the quality of the software, but instead talk about what the product will do for you. The latter approach tends to be more successful, unless you really are selling a software product to be used by software developers. In which case they might actually care about and inspect the quality of the code they're getting -- but probably only after the contract is signed and it's too late.

    It reminds me of the CEO or VPE of every tech company I have ever worked for, who goes on at great length about how his company hires only "the best and the brightest" developers out there, how we're the "cream of the crop", how we have a "team of all superstars". Well, but of course we are! Who would want to work for a team of halfwits and losers, or even a team of the good but not the great?

    It's great ego pumping when you're young enough not to have heard it before, but I'm going to let you in on a little secret: I am neither the best nor the brightest out there. I'm somewhere between the cream of the crop and the scum that floats to the top. And my only connection to superstars involves jumping around a living room in my underwear, and I'd rather not say too much about that. At the same time, the CEO/VPE isn't lying. In fact, he probably believes every word that comes out of his mouth; it's part of the mental defect that makes you capable of reaching that sort of position. It helps you sell, I think.

    Sorry. Kind of got on a roll there. The only other thing I wanted to mention was that you're only talking about code quality. More relevant is product quality, which is measured by more than the code or even the spec. Code quality is a horrible predictor of a company's success (sometimes it's even backwards, when you spend too much time pumping "quality" into something that customers don't want or is rapidly being obsoleted by a lower-quality but cheaper and shinier competitor). Product quality has a better correlation -- although the extent of the CEO's brain defect can often trump even that, especially in the early stages of a startup.

Re: What is quality?
by rodion (Chaplain) on Jul 28, 2006 at 03:02 UTC
    jimt says (provocatively)
    You're an awesome programmer and you write the best stuff. And my response? "Prove it."
    And my response to that has to be, "No".

    Quality is not something to be "proved". You can make arguments, demonstrations and provide evidence that the quality of something is higher than the general run of similar things, or higher than something else, but quality is a multi-faceted concept that has too many thing going into it to say things like "this has 5.7 more quality units than that, plus or minus 1.37." That's just a bit silly.

    This doesn't mean that the concept is meaningless, even though marketing hype has made its meaning harder to find. Many things we value can't be adequately quantified along one, two or seven dimentions.

    • "I enjoyed that {meal|music|tenmis game|user interface}."
    • "That's an elegant {proof|vase|algorighm}."
    • "That {argument|expanation|alibi} makes a lot of sense."

    There are some very useful and informative things that can be said to support these statements about complex things, and some things that can be usefully quantified as well, but it's a mistake to think you can boil it all down to something provable, just as it is a mistake to suppose that just because something can't be proved there is no meaning to be found in it and nothing worthwhile there.

    After all, the completeness of Mathematics and the effectivness of proof in Mathematics can not be proved, but Mathematics is still pretty useful.

    So, what are useful guides to quality? What have people found to be good early indicators that they will later think of a piece of code as

    • performing well,
    • easy to learn and/or use, and
    • easy to maintain?

    Albannach and eyepopslikeamosquito have given us a start, and I'm interested in hearing what others have found useful

    If it were so simple that ISO 9000 could give us the answer, we wouldn't have enlightening discussions, now would we.

Re: What is quality?
by liverpole (Monsignor) on Jul 28, 2006 at 12:18 UTC
    Your post on quality reminds me of a funny, true story from about 6 years ago.

    I was working with a Japanese customer (well-known for their attention to the most minute details and propensity for stringent demands) on solving an O/S issue they desperately needed to have fixed.  They were meeting us to go over the QA schedule, and to get assurances that we could meet their deadline, which could NOT be extended.

    So we all sat down, and the first thing they mentioned was that they wanted to move the target date back by 3 days (thus giving us 3 days less at the end of the project for quality assurance), and we said "sure, that shouldn't be a problem".

    Then we started talking about how the project would be tested, and the first thing they asked was:  "Since you have such a tight schedule, with so little time for testing, how can you guarantee us that this project will be completed without any bugs?"

    The irony was so thick you could cut it with a knife.

Re: What is quality?
by ptum (Priest) on Jul 28, 2006 at 16:20 UTC

    I don't think the concept of quality is anywhere as complicated as you make it out to be.

    Let's take your example of claiming that your software is all very 'gloomf'. So I'll ask you a few questions:

    • How do you measure gloomf?
    • Who is responsible for checking your software for gloomf?
    • How long do you spend evaluating your software for gloomf before it is rolled out?
    • To whom do the gloomf-assurance folks report?
    • What is the ratio of gloomf-assurance folks to developers?
    • Do your gloomf-assurance folks have veto power over software rollout?
    • What is the ratio between gloomf failures before your software is rolled out, and gloomf failures after your software is rolled out?

    If you can't measure gloomf, I'll know you don't have any, or if you do, it's by chance. If you measure gloomf, but you get it wrong, I'll know you are well-intentioned but clueless. If you don't have many gloomf-assurance folks (with at least some power and a level of independence from the development management) or if you don't give them much time to ensure your software is gloomf, then I'll know you are gloomf-challenged. If there is no discernible difference between gloomf failures detected before software is rolled out and gloomf failures detected (presumably by customers) after the software is distributed, then I'll know that you either have crummy developers, lazy gloomf-assurance folks, or very adventuresome customers (or perhaps all three).

    There are a lot of things that can't be proven, but we still can hedge our bets. When you apply for a mortgage, the bank tries to cover its investment by assuring itself that you have future earnings potential. You can't prove that you will continue to earn money, but you can show your W-2 statements over the past several years and demonstrate that, if the past is a decent predictor of the future, you will be able to pay your mortgage. In the same way, we can assure ourselves of quality in future use of software by demonstrating that we have exercised due diligence in the software development cycle.

    The happy news for software developers is that there is so little quality out there that even a little can give you a substantial competitive advantage. I used to do QA work for a major online retailer and I took a lot of pride in finding bugs in software before it was rolled out, often very hurriedly. If you have ever worked with a competent QA person, you know that they are worth their weight in gold, and you tremble when you turn your software over to them. Some things cannot be strictly 'proven', but you can provide some pretty decent safeguards and assurances that at least you tried to get it right.

    Heck, you might even qualify for a mortgage.

    No good deed goes unpunished. -- (attributed to) Oscar Wilde

      You're right, to at least a significant extent, of course. On the other hand, you're addressing a narrow field of software development, and quality can be measured, created, and "proven" differently in other development circumstances. The example that sprang to mind while I was reading it is open source development.

      Within (successful) open source software development projects, QA personnel vastly outnumber core developers — and yet, a great many QA personnel turn into patch developers, while core developers become in essence project managers for bug fixes. The model further diverges in how one can recognize quality: you can track the very public management of bug fixes and the development process, and even view the code. So can everyone else.

      Ultimately, the difference is to a great extent the relative ease of measuring its quality.

      I had more to say — profound, wise stuff, of course — but I got distracted by the fact that Edward Scissorhands is on TV, and I forgot what I was going to say.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

        Within (successful) open source software development projects, QA personnel vastly outnumber core developers...

        That's not a good sign for Perl 5.8.9 then, when the pumpking puts out a release candidate and gets fewer test reports than there are people with active commit access to the repository.

Re: What is quality?
by spiritway (Vicar) on Jul 29, 2006 at 15:18 UTC

    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.

      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".
      Maybe. However, my experience has been that marketing folks tend to oversell the importance of being first to market. Quoting Alan Cooper from The Inmates are Running the Asylum:
      Shipping a product that angers and frustrates users in three months is not better than shipping a product that pleases users in six months ... A third rate product that ships late often fails, but if your product delivers value to its users, arriving behind schedule won't necessarily have lasting bad effects ... Microsoft Access shipped several years late, yet it has enjoyed formidable success in the market. Conversely, if a product stinks, who cares that it shipped on time.

      In 1990, the PenPoint computer from GO was first to market. Then followed the Apple Newton in 1992. Then General Magic's Magic Link in 1994. Finally, in 1996, six years late, the PalmPilot arrived to win the market. Hmmm, let's hope Perl 6 emulates the PalmPilot. ;-) Conversely, can anyone name a current market leader who was first to market?

        Often, however, getting to market faster, before all the bugs are worked out, is the only way to survive. Many companies have gone under after producing excellent merchandise late because of costs incurred and time to penetrate the market.

        If someone beats you to market with something desperately needed, but does so by offering a mediocre finish rather than doing it "right" that someone gets instant market penetration. If you come along later with a clearly superior offering, you could easily steal the market out from under your competitor. For that to happen, though, people need to recognize the quality of what you're selling.

        It takes some time for people to evaluate the new entry into a market that is already "owned", even if only tenuously. Running late on production usually means running over budget as well. Once you get your product to market, you have to be able to survive long enough for people to buy what you're selling. That's when many vendors and producers of the late, superior product falter. So much for your superior product.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

        You've got a good point there... I can't think of anyone that I *know* was first to market... still, I've seen lots of companies come and go, some of which seemed to have a good product. My impression was that they died because they were too late. OTOH, maybe the difference was that the other company wasn't all that bad to begin with - not *mediocre*, necessarily, just not quite as good. So maybe "good enough, soon enough" is what really wins... You've given me much to think about. Things are never quite as simple as they seem at first look...

      spiritway, today: "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."

      MacUser, November 1990: "There comes a time in the history of any project when it becomes necessary to shoot the engineers and begin production."

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

        That's very similar to something I read about artists - and that I believe applies to software developers. The saying was along the lines of "(an artist|a programmer) doesn't finish a work so much as s/he abandons it." I guess if they won't abandon it, you have to shoot them...

Re: What is quality?
by Anonymous Monk on Jul 28, 2006 at 16:34 UTC
    So you're basically hoping that I never begin to think that your software is low quality (and, remember, for this example we're assuming it is), because once I make the connection, I'm off to another vendor. Admittedly, they may also be poor quality (again, in this example I'm a poor judge), but the point is it's no longer you I'm doing business with.

    You would think that this would be the case. In more cases than one might expect, it's not.

    Last night, my girlfriend and I went to a coffee shop near her house. She complained that the service there was terrible, and told me about various complaints and arguments with the managers. She still shops there, because it's right next door to her house.

    Microsoft has demonstrated repeatedly to it's customers that their software has low quality. People still stay with Microsoft, though, because there's a learning curve associated with change.

    The local phone company has horrible customer service. I'm still with them, because I haven't taken the time to pick one of the new alternative carriers and sign up for one, although I'd certainly like to. Until I do, the lousy phone company still is still taking my money...

    People don't like to change their habits. It's not a matter of intelligence; it's a matter of convenience. I'm convinced that laziness drives the universe more than most people are willing to admit. Certainly, formal logic is a poor predictor of human behaviour patterns...

      Microsoft has demonstrated repeatedly to it's customers that their software has low quality. People still stay with Microsoft, though, because there's a learning curve associated with change.

      The "learning curve" argument is, for the most part, just an excuse. After all, you could always go with a Mac and have essentially no learning curve at all. I think it's mostly a problem with intellectual laziness (people don't like to take responsibility for significant decisions) and ego identification with the decisions they've already made (people don't like to admit they're wrong). There are other factors involved, of course, but I think those are the biggies.

      I have run across a veritable cornucopia of excuses for a refusal to consider other alternatives. One of my favorites is the technology "investment" excuse: if you've already spent $30,000 on your Windows solution, that somehow seems to justify continuing to spend $600 a month on software maintenance and licensing rather than "throw away the investment" to go with $2000 in setup fees and nearly zero-cost upkeep for an alternative, open source solution that you might even discover better suits your needs if you took the time to evaluate it. Of course, that's not to say that changing technologies is always the best option, but hundreds of thousands of businessmen will never know because they never make the effort to find out. So it goes.

      It's a bit like politics, too. People continue to vote for a candidate from one alien lizard clan to keep the candidate from the other alien lizard clan out of office. Humans just aren't programmed to be comfortable with choices any more complex than binary decisions, and they even try to avoid those as much as possible; if a decision has already been made, it reduces the number of decisions they have to make in the future, and woe betide the guy that tries to convince them otherwise.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

Re: What is quality?
by radiantmatrix (Parson) on Aug 01, 2006 at 15:06 UTC

    A big part of the problem with defining and quantifying is a linguistic one, and it comes in two pieces:

    1. the idea that the term "quality" represents is subjective, and therefore the word "quality" means different things to different people, and
    2. we refer to "quality" as an attribute rather than a perception.

    The first is pretty obvious, so I'm going to avoid getting into more detail on it (unless someone cares to have that conversation).

    The second, though, is tricky. We often say that things "are quality" or "have quality" -- or even "are of the highest quality". Those phrasings suggest that most people think of quality as something bound explicitly to a product -- product X has more quality than product Y. This leads to attempts to quantify and thereby measure "quality" in such a way that is universal, so that numbers can be plugged into a spreadsheet and the "highest quality" product can be empirically chosen.

    Unfortunately, quality is not an attribute of the product but an attribute of the observer. What we really mean when we say we want a high-quality product is that we want a product that has been designed to fit our perception of quality. This is important, so let me rephrase it in more practical terms: a quality product is a product that does what its customers want it to do.

    When it becomes necessary to look at quality from a broader view -- that is, not with regard to a particular set of customers and their needs -- we neccessarily limit ourselves. This is, of course, useful. But, look at what we do: we define quality in terms of what the majority of people want products to do -- be consistent, not break, be affordable, be intiuitive, etc. We then apply processes, methods, and technology to assure that our products meet all of these common goals, and to ensure that any given product will meet the other (more specific) needs of a customer.

    The problem in perception usually comes as a result of a phenomenon every developer is painfully aware of: most customers don't know what they want. As a result, producers who can anticipate their customers' needs and desires and incorporate them into a product will be percieved as higher-quality than those that only respond to the requests and specs provided by the customer. In other words, they key to quality is knowing what the customer wants even when they don't know they want it.

    Of course, all of this means that "demonstrating the quality of a product" really is "convincing the customer that the product meets all their needs". The fact that I have a test suite demonstrates to my customer that I will be able to modify the product with a low risk of breaking things. This is a customer need: they need to be able to get new functions without breaking old ones.

    Pretty much any rule that you can point to and say "quality software must have this" can be directly tied to a common need of the majority of customers. Standards compliance? Customers need interoperability and protection against vendor lock-in. Graceful degradation? Customers need to be sure that core functions operate in adverse situations. And so on.

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://564190]
Approved by ikegami
Front-paged by apotheon
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (None)
    As of 2024-07-21 14:15 GMT
    Find Nodes?
      Voting Booth?

      No recent polls found

      erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.