raganwald
Thursday, July 17, 2008
  What does the word "Quality" mean?
The phrase “Quality Code” came up in a conversation with some colleagues. Just so we’re clear on what I mean when I use the word “Quality” with respect to code or architecture or software design:

Quality is the antonym of “defective,” with the addition of time. Meaning, it has few known defects in its current state, and we have high confidence that we will not discover defects in its current state over time, and additionally that we will not create further defects in it as we add to or alter its functionality in the normal course of maintaining this software.

That’s a lot of blather suggesting that quality in a code base is all about making code that works as expected. Some code is designed to be extremely flexible or malleable to make it easier to add functionality in the future. This is an admirable property of a code base, however I do not think of that as affecting a code base’s quality except for the fact that a more flexible code base does sometimes allow adding functionality with a lower probability of introducing new bugs or regressions.

I am not attempting to sum up all of the desirable properties of a code base. For example, in some business circumstances, increasing velocity of development at the expense of quality is a good trade-off, such as when putting together a demo that wins a large piece of business or when creating prototypes that users can use to hone a design.

But when I talk about code having very high quality I mean that it has few defects and that I expect it to continue to have few defects over time. Code that is extremely brittle and highly coupled is not of high quality because I expect that any attempt to make changes will introduce regressions.

Thus, the word “Quality” is not a subjective, aesthetic judgment. It is an objective measure of one axis of value to its owners.
 

Comments on “What does the word "Quality" mean?:
The classical "Zen and the Art of Motorcycle Maintenance" deals with Quality. According to the book, trying to define what quality really is in an analytical fashion might drive you mad. So take care!
 
You have to consider 'quality' over a long period of time. Just because the code isn't breaking today, while its author Joe is still working on doesn't mean it's not a landmine waiting to explode.

Quality is almost a relative metric, I prefer the term elegant, breaking down into simple, complete and readable: Readability

Paul.
 
Axel:

Yes, I am delighted to savour the “Quality without a name.” Thank you for reminding us of this. But as it happens, that’s not what I mean this time.
 
Paul:

I also like elegance, however that’s not what I mean this time either, excepting as elegant designs—in my personal experience—happen to produce quality over time. Therefore, I can say that the elegant code I have observed has been of high quality, and the inelegant code I have observed has been of low quality.

However, as you point out, that does not mean that elegance and quality are synonymous, any more than saying that horsepower in an engine is synonymous with speed.

Quality is a measure of the result, elegance is a description of one way to achieve that result.
 
So in a sense, a bug-free version of one of the obfuscated C contest entries is high-quality code, in that there are no defects?

The big thing I see with this type of metric, is that it is too 'timeless'. Code for a contest is frozen in time, but code for a real live production system is constantly changing.

The previously mentioned contest entry code will eventually need to be altered. At that point, because it is obfuscated, the changes will go horribly wrong, and the 'quality' of the code will flip-flop. The high-quality code will become low quality.

If we take the broad view, over its lifetime, the code was only low or medium quality at best, that or it's just blind luck that the code was never fiddled with.

In a sense the high-quality moniker is only there because all of the information about the 'quality' of the code is unknown at the current time. If we mis-label it, is it really high quality?


Paul.
 
Paul:

I have this odd feeling we are in violent agreement. You said:

If we take the broad view, over its lifetime, the code was only low or medium quality at best, that or it's just blind luck that the code was never fiddled with.

And in the original post, I said:

…it has few known defects in its current state, we have high confidence that we will not discover defects in its current state over time, and additionally that we will not create further defects in it as we add to or alter its functionality in the normal course of maintaining this software.

So I can say this: if code actually never is modified, such as code burned into one-off hardware we send into space, quality is a measure of its current state only. But that is obviously an exception, and people writing such things probably don’t come to me for ideas and advice.

But if we expect the code to change over time—which is every single piece of software I have created professionally—I interpret our statements to be in concordance.

Do you agree?
 
UPDATE:

Rereading my words, I wrote something like “Quality is A, B, C” meaning that I interpret Quality to mean A+B+C, but maybe it comes across as A therefore B therefore C, which is something else entirely.

I am updating the original to be more explicit.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /