Quality ≠ Perfection
A perfectly crafted piece of bug-free software – every developer dreams of working on such a project. And I can’t imagine a user who would dismiss such software. There are plenty of articles on the web on how to improve your code. Dozens of agile coaches strive towards increasing your skills on producing better and better software. Everybody aspires perfection. Unlimited perfection?
Even though everybody wants perfect software, I have never met a customer yet who was willing to pay us for making his software perfect, no matter in what application domain. Isn’t that weird? I mean, every customer expects a Bentley but he is only willing to pay for a Beetle? Sales has got to fix that, they just have to work harder and make the customer pay for our premium quality, I used to think. Unfortunately, it doesn’t work like that. I saw that we somehow needed an approach to produce medium quality at a reasonable price.
But which customer accepts medium quality, I asked myself? – Well, to be honest, I do. Let me give you an example:
When I go on vacation, the whole family and tons of baggage stuffed in my station wagon on an eleven-hour trip to a vacation home near the French coast. At lunch time, we will need something to eat. We are on the highway near Lyon, so L’Auberge du Pont de Collonges of the famous Paul Bocuse isn’t far. It has 3 Michelin-Stars since 1965 without an interruption. Rock solid prime quality! But – a detour of on and a half hour plus the hours and hours spent for the lunch itself like in every better French restaurant? Hmm. And will the kids like the fancy food? Don’t think so. All the extra time and all the whining – am I willing to pay that price (besides the bill)? Well… Oh, I forgot to book a table months ago, so this decision is easy.
If the top-quality option is too expensive for my current needs, let’s select cheaper, something to spare time. But believe it or not, the country de la haute quisine, the home of the Guide Michelin offers some horrible motorway restaurants! Not all of them, some are acceptable, but most are really disgusting. Can you imagine an irritated dad, a hangry mum, and a couple of overtired kids playing culinary roulette in questionable French motorway restaurants? Well – only once or twice. “Insanity is doing the same thing over and over again and expecting different results.” — not Albert Einstein.
Our option on long trips is a classical Mackie-D for a couple of years now. Low risk in tense situations! The food has medium temperature, it is medium fresh (some fresh and some industrial components) and medium tasty. The restaurant has a medium nice atmosphere and the toilets are medium clean. Almost never outliers up or down. This is what I call quality management! All properties reliably at medium performance – at a reasonable price. This is small plea for (controlled!) medium quality products (not so much for a certain chain of fast food outlets).
So, if for economic reasons perfection is not desirable then there are two approaches to save effort (and thus budget) with respect to quality: a) completely ignore certain aspects of quality and let lady Fortune decide on the actual properties my product will fulfill or b) identify properties where I can pilot my product to a certain ‘acceptable’ performance. An example for the former is application security (assuming it is not part of the customer’s requirements): I can decide to completely ignore any security aspects of my software product. I will not design it for security, will not analyze it for security flaws, I won’t do any penetration testing and I will not update my dependencies in case of security bug fixes. Obviously, I can save tremendous effort. Whether the resulting software will be secure or not is left to chance. Not impossible but doubtful, the least. (And you won’t even know – maybe your customer will find out.)
From a certain perspective, this example can be viewed as a special case of the second approach as well: At least the property is identified and can thus be regarded as ‘controlled’, even if the performance is actively piloted to zero. A better example to explain how to pilot a property to a decreasing or mediocre performance may be the source code structure: Usually, you always strive for good code structure to keep it maintainable and keep the cost of changes low. But if this is the economic reason for good code structure and spending budget on refactoring – what about software products in on the eve of their end-of-life in their application lifecycle? You could stop any refactoring deliberately accepting increasing effort and cycle times in ticket handling. You just have to estimate your breakeven point. Other examples comprise the esthetics of the GUI or the number, helpfulness, and localization of error messages – and generally the field of usability.
P.S.: Document and communicate the properties with restricted performance! Otherwise somebody might start tidying up your code of file bug reports for odd fonts.