On Quality: Quick and Perfect! - IV

Well, we reached a point in our discussion on “Quick & Perfect” postulate where we have to answer the question: If the cost of imperfection can be that deadly, then are there any ways, or hopes, that the C.O.P (cost of perfection) gets to be affordable? The answer is our topic for this article.

I’d like to introduce to a principle that I’ve developed over decades of practice, and I’m really comfortable with to the rest of my professional life. That’s what I call l The Principal of Economic Perfection. It states that:

If you are well prepared for a complex job, then perfecting it in the first  place is less costly than correcting defects you do in it

Let’s take it bit by bit, watching the underlined italicized words in its phrasing:

  • First we are talking here of “complex” jobs, and any non-trivial software development task has its share of complexity by nature, in varying grades of course. So we are within the domain of the principle.
  • Second, we are talking “well prepared”, so we are supposed to be having the experience and pre-knowledge of what we are up to and this makes our trial to do a perfect (faultless) job from the beginning feasible. The more we master what we do, or be prepared for it, the less time we take and the less cost we pay for such an attempt of perfection.
  • Thirdly, the principle states that in complex  systems or jobs, where dependencies and interactions are many, detecting the cause of an error, not  to mention correcting it, is certainly representing an  unpleasant and time consuming job.  In his seminal work “Practical Software Metrics For Project Management And Process Improvement”, Robert B. Grady estimates a ratio of 1 to 10.

Thus, the final essence of the principle is that if we know what we do, then pursuing perfection in doing things perfectly outright  in the first place is less costly than falling into errors and then exerting efforts on costlier detections/corrections. However, and let me re-emphasize, this is not possible except under the assumption that we own that attribute called “Preparedness”.

But what is “Preparedness”, exactly?

The answer is,  by and large, the outcome of almost six decades of experience, studies, trials in Systems Engineering that our industry has seen, that all boiled down to the methods that we must master in order to own that attribute  called “Preparedness”. We need  to trim that further and get it into some doable techniques, I know.

That’s our topic for the coming article.

See you, then.