(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
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:
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.
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?”:
<< Home
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.
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.
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.
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.
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?
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.
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
