On Quality: Quick and Perfect! - III

 

In the previous two articles, I claimed a more so far “unrealistic” redefinition for software quality as “How far we are from Perfection”, in other words, software quality is our best effort to attain perfection.

As I expect, being under such a hysterical delivery pressures, you (if you are a software manager) will shrink back furiously, in preparation to a fierce attack! Hold on and let’s discuss it seriously and sanely.

Before I start, let me just set some pointers here: quality is truly a multidimensional space. We have the Functional Quality that maps  customer’s use cases to live functionality on the given platform, conveyed through some subliminal  Structural Quality represented, at least, by Reliability, Sustainability, Usability, Performance and Security. Let’s, for the sake of discussion, define  a “Defect” as any deviant from an expected, well-behaved pattern in any of these dimensions of the quality complex, in any way that will prevent the user from achieving his goals partially or totally.

Now, back to the initially rejected notion of Perfection, where the biggest question is “How costly is Perfection?”.  When an answer is hard to attain, let us use some Lateral Thinking and ask the opposite, “What is the cost of software Imperfections?”. We know the answer here! Just  let’s recall our well-known natural behavior of any newly developed system, depicted by Fig. 1.

Systems are released with some threshold of defects infused in them that no one could reach during all tests. The time that a system takes to reach a satisfactory MTBF, or stable state, its Stabilization Period, is definitely very costly for the software manufacturer, in at least two ways:

  • By nature the CoC, Cost of Correction, for a system in actual operation is by far exceeding that while it is still in house on the test rigs,
  • What about the customer? Undoubtedly,  the frequency of post-installation defects, as well as their nature and impact, are dead sources of user inconvenience, directly impacting the manufacturer’s image,

So, this critical period in the lifetime of any system can sometimes not only eat up the earnings of the software maker in the project, but also can shake his reputation among snatching competitors.

That answers our lateral question about “Software Imperfections”:  when not kept to a manageable minimum, they represent a real threat to a software maker. It follows that the answer to the original question is that a trial to deliver a system that is near perfect is, at least, worth consideration.

Now, we are left with another question here to reconsider Perfection: What about the CoP, Cost of Perfection? Are there ways to think of that Perfection as a non-costly process, one that is not cheap, but still feasible, justifiable and economic.

That’s our topic for next article. See you then.