What Is Quality
What Is Quality[Please note: "Quality" can be defined using the Phil Crosby definition found on QualityIsFree -- "Quality is conformance to requirements." The remainder of this page is a discussion of vague generalities and PersonalChoiceElevatedToMoralImperative.]
What is quality? I'm primarily interested in what is software quality? But, it might be interesting (useful, even) to discuss the attributes of quality in general and then reason to the specific attributes of software quality.
We talk about it all the time. How rushing this or cutting that will reduce the resulting quality of our software. But, what is quality?
It is not simply the number of bugs in a program. If that were the case, we wouldn't be terribly concerned about SelfDocumentingCode or OnceAndOnlyOnce. Perhaps it's a ratio of bugs introduced per unit feature per unit time to implement?
Quality is closely aligned with KentBeck's rules of SimpleDesign [c.f. XpSimplicityRules]:
but couldn't spaghetti code full of GO TO statements, overloading (etc) also satisfy those rules?
I don't think that spaghetti code is very expressive. Sure, it provides instructions to the machine, but it doesn't express ideas to the reader of the code.
Can I provide RealValue without providing quality software? I contend that I can. It may be true that software of higher quality will provide more RealValue, but this is true only up to a point due to the decreasing marginal return of quality
No argument. But can you provide quality software without providing RealValue? Is value part of quality?
RealValue measures the desirability (by whom?) of an entity. Therefore, you could have software that was well written, but did something that no-one wanted. This would be quality without value.
Agree, this would be quality without value. So perhaps the question needs re-stating: Should value be part of quality? (-- RandyStafford)
You may be interested to know that this exact topic has been covered quite rigorously by JerryWeinberg in his books titled QualitySoftwareManagement. According to Jerry, "quality is value to some person", which of course means that a single product has as many degrees of quality as people using it, more or less. -- WaldenMathews
Quality is a metric of goodness, or utility, or any other desirable attribute.
Value is a metric for exchange or trade, often determined by a combination of various qualities.
So, both quality and value get down to desirable attributes.
Philosophers have been arguing about the nature of quality for most of recorded history. RobertPirsig sent himself nuts trying to nail this one down in ZenAndTheArtOfMotorcycleMaintenance.
But he eventually regained his sanity and wrote LilaAnInquiryIntoMorals in which he developed TheMetaphysicsOfQuality where he does "nail it down".
I agree that quality is not easy to define. From my dictionary: "quality - see excellence, excellence - see quality". However, I think a lot about the issue of software quality so I'm willing to take a stab at it. Could software quality be the potential to create RealValue (i.e., ExtremeNormalForm)?
As a maker, I value things like SelfDocumentingCode and OnceAndOnlyOnce - I consider these attributes of quality code - because I know that when tomorrow's problems come I'll be in a better position to face them. With quality code I'll be better able to provide the RealValue the customer is paying for.
Perhaps it is just a level of indirection. Software quality consists of those things that provide value to those of us whose job it is to provide value through software.
Indeed. Much software is written with the context of there being ongoing work on the code base. For this software, quality would have attributes of easy to maintain. Some software is written from scratch with every hack and tweak imaginable, producing the most obfuscated spaghetti code this side of a western ... where this is done deliberately because the code has to be squeezed into a limited environment (ie. embedded), then it's compactness contributes to it's quality.
No matter how good or evil your software is, no matter how good (or evil) you think you are at measuring how good your software is, all software has a single quality that is responsible for all this chatter about Quality, and that quality is: Softness.
Stating the obvious again, right? Sure, but did you know that the word quality did not start out meaning what you think it does? It started out meaning "type" or "kind". "What quality of sweater is that?" It's wool, thank you.
So, the next time somebody asks you about the quality of your code, prepare for them a listing of the types, and defer the simple minded judgments and all the baloney measurements that go along. Or, at the risk of having an online dictionary thrown at you, you could just softly reply "soft".
Moved from WritingGoodCode
What are the qualities of Good Code? A lot of discussion goes into how to produce good code, but what is it we are trying to make?
A few possibilities:
Extensible
Code is always extensible. You can always add another line of it. A better word is malleable, i.e. easily extensible.
Understandable
Good code should have aesthetic appeal "on the page", achieved by good spacing and indentation. This should reveal structural attributes of the embedded logic at a glance. Symmetry, as they say in the body shaping business. This is the typographical consequence of a certain mentality at work, the same mentality that refactors (logic) mercilessly.
What exactly are we trying to do?
"Good code" might be what you care most about, but Business has a different view. They don't get to see the code, only the product. If we'd like Business and Development to see eye to eye, we might want to focus on "good process" instead.
In this view, doing a project within the given time and cost constraints is a primary goal, with "good process" leading to "good design" and more incidentally to "good code". The latter achievements only help to safely reach the former.
[I see] good process [as] a means to the end of good code (and hopefully also good documentation, good customer relations, etc). To me, that makes it secondary. On the other hand, perhaps you can do well by concentrating on good process and forgetting about writing good code, in which case good code would be (practically, not in principle) secondary. I am not convinced, though. If the people writing the code aren't trying to produce good code, then either the process is broken or they are.
When you use multiple layers of leverage (process, design, code) to accomplish something, as you are talking about here, it's dangerous to focus only on one layer and ignore the others. It forces you to give up either power or validity, and neither is a good choice.
Lest we descend into a tail-eating circle of analysis: Good code is What I Like. Everything else is junk.
When the tail is all eaten, only the good code will remain. Just kidding.
Part of the intent of the original question is to determine how to measure the success of a process. Certainly we don't want to focus solely on coding, but how do we know if a process is producing good code without know what good code is?
Juran (I believe) defines quality as "fitness for use." An artifact's quality, then, depends on what you want to use it for. A gorgeous solid crystal wine goblet makes a really low-quality hammer.
In software, there are at least two broad categories of uses - the user of the running software (the user's use), and the use by programmers in an attempt to make a different version of the software (the programmer's use). A useful program that's impossible to modify has high-quality in the first category but not the second; a highly habitable program with a geeky user interface meets the second but not the first.
I would argue that the second category is subservient to the first. If the end users do not benefit from a change, then the change is pointless at best. One of the benefits of implementing things in software is the ability to change (something which software QA often ignores or rejects). Keeping software changeable is a user benefit and that is why it is important.
EditText of this page
(last edited October 29, 2014)
or FindPage with title or text search