עברית
Quality.
Don't we just love this word? It gives us that warm and fuzzy feeling of doing something well. But there's something wrong about the way we use it.
I've started thinking about it when I was processing my disagreement with the 5th principle of modern testing and mentioned Jerry Weinberg's definition of quality - value for someone. Then, shortly after, a lot of distractions took over (one very positive such distraction was European Testing Conference) and I put this issue aside for a moment, at least until other things reminded me I had some more to write on this subject.
So, what do I mean by "broken"? Or rather, why do I say it's broken? To answer that I want to go back to school and to the definitions of the trigonometric functions. More specifically, to sine & cosine.
When we were first introduced to the idea of a sine it was through a question: since we know that the relative edge sizes of similar triangles is the same, what can we tell about the size of a right angled triangle's legs related to the hypotenuse? To answer that question we introduced two new mathematical functions - the sine and the cosine. School being school, we went to practice it for a bit, calculating the size of various edges. After getting used to it, the teacher asked a question: What would be the value of a sine for values that are less than zero or more than 90 degrees? The action, at least for the moment, was undefined. Well, what about a new definition? The value of sine(a) for any angle a is the y value of the intersection point between the unit circle and a radius forming an angle of "a" with the X axis. cosine shall be defined to be the x value of that same very point. Great, right? Now we can have this function defined for whichever value we want, and can even deduct some cool properties of those function rather easily (for instance, cosine(x)=cosine(-x)) There's only one thing to do - prove that the new definition does not contradict our previous definition, and it agrees with it at any point where both definitions hold. This proof is rather easy, and the studious readers can complete this exercise by themselves, but this is where I return to the definition of quality in software. Something in the way we define quality is broken. Our definition is inconsistent with the definition of quality in other domains. Moreover, the properties displayed by "quality" examples outside of software are very different than those displayed by software.
Picture an armoire, and not a simple, generic one, a sturdy, dark mahogany armoire, with double doors decorated with fine engravings and polished brass handles. Do you have a picture in mind? Great. Now picture another one, roughly about the same size and shape, made out of plywood, assembled by you with the help of the very detailed Ikea guide, with most screws fitting snugly into their dedicated sockets. Which of the two would you say is of a better quality? Which one are you more likely to see in someone's appartement?
Most people would answer that the mahogany armoire is of better quality, but that the Ikea one is more likely to be used. Why? Because it's cheaper, more accessible, and it doesn't really matter a lot if your child would draw on it with crayons. It might be of lesser quality, but the price is low enough so that we won't mind replacing it every decade or so, and we might even look at it as an opportunity to replace and renew the furniture, which can be nice. Also, if we move to another apartment, as some people do, it will be much easier to leave that armoire behind or resell it instead of going through the fuss of taking it with us. Quality is not the same as "being used a lot", and in fact, the extra cost paid for quality usually makes it used less.
It's not only physical goods that have those properties, if we'll wander to the realms of literature for a moment and compare The Harry Potter series to the Iliad we'll see that the same is true there. Most people would agree that the Iliad is a masterpiece, and that Harry Potter, which sometimes is having difficulties even keeping consistent with itself, is not1. And yet, Harry Potter is being purchased and read far more than the Iliad. Despite the fact the most people would rather spend an evening reading Harry Potter, "quality" is not the reason they do it. In fact, with the exception of software, quality items are less common than their shoddy counterparts. Why would measuring the use of software be any indication of its quality?
We can try to understand the reasons behind this conceptual mistake, and I have my own lousy guesses, but that's not really that important. What is important is to understand that when we use an improper term (or use a term improperly), we mess up all of our gut feelings. It means that we are trying to use quality processes to solve marketing and sales problems, or that we borrow some odd measurements and processes from other fields that mention "quality" (Can anyone explain to me please how on earth did 6-sigma make its way from manufacturing to a presentation about software quality?) This mix also sends us chasing our tail trying to achieve "quality" in places we shouldn't. And, obviously, it causes many people to waste a lot of time and words trying to define "quality" (I considered looking for a link or two for examples, but what have you been reading here up until now?).
As software people, we should stop treating quality as a goal by itself and remember that it is one property that might help us achieve our business goals. When we think about it like that, it is perfectly fine to skip a meticulous definition of this term, since "I'll know it when I see it" is good enough for a single (not that important) property of what makes a project successful. Most importantly, we should embrace the fact that in software too, it is acceptable (and common) to look for Ikea-level quality.
1 I'm not claiming that Harry Potter is bad - it is fun and fluent and has many interesting things in it, it just isn't a masterpiece ↩
No comments:
Post a Comment