Myth of Zero defect Software.

I am sure that anyone who has gone through a complete software life cycle will understand what I am talking about. As the release date starts nearing, discussions starts on the number of defects that are still open and how we plan to address the same. This debates proceeds almost till the date of the release and many a times as the software is released, a plan for the "Service pack" that will address critical issues that have seeped through the product is put in place.

Many of these discussions are painful and one of the primary reasons for the pain is due to the different perceptions on "Quality" of the software and whether one can say with a "clear conscience" that the product is ready to ship even though he knows that there are defects in the software. Obviously a good software practioner will not want to cause undue to pain to the end user of the software.

If one scans through the litrature on Software quality, we will find two broad views. One view which leans towards shipping defect free software and the other leaning towards shipping software with "Acceptable Quality".

I am not a great votary of "zero defect" software concept. In my view the goal of "zero defect" is achievable in manufacturing and related fields but is a very difficult goal in software engineering. "Defect" by its very name implies non conformance to a specification. This means that to have zero defects, we need to have the specifications spelled out completely and correctly. How many software practioners (especially people building comercial software) been exposed to a "Complete and correct set of specifications".

Over the release, software evolve and simultaneously the specifications also evolve. Software engineering is constrained heavily by the schedule and cost. Business mandate more features, in less time and with lesser cost. Given this reality, any goal of having a fully qualified specification will end up as mirage. My personal view is that, having such a goal itself is absurd. A good software practioner has to factor for change/modifications and should be able to control it.

In absence of a complete specification, the goal of a defect free software also end up as mirage and an absurd goal. On the contrary an ideal goal would be to define "Acceptable Quality". Doing so will remove the ambiguity and pain people undergo when making a decision on whether to ship or not ship the software to the field.