One of the most arguments that seems to dominate the world of agile development is around the concept of zero defect software. While I agree with the points that Dr Neil raises about zero defect software being in part a mindset – if you think you write bugs, you will write bugs – I disagree that software can remain in a zero defect state. In fact, as the title suggests I think that there needs to be two adjustments to the term. Firstly, the concept of zero defect is almost impossible, unless you use formal methods, or equivalent, to prove your software is “correct” (which of course overlooks the discussion around what “correct” is). Hence the “known” augmentation – you can preserve the zero defect state, so long as you know what the defects are.
The second addition is the word “unacceptable”. Take the example where you are building a product that integrates services from a number of vendors, each of which provides their logo to be displayed in the application alongside their functionality. During the development phase one of the vendors changes their marketing campaign, including their logo. Of course, you now have a defect in your software that the logo is wrong. This isn’t a feature or enhancement, the logo is wrong (although I’m sure that some will argue this point). Given that you have a number of outstanding features that need to be completed before you can ship the current version of the software do you spend the time to fix this issue? Or do you mark this defect as “acceptable” and move it to the next release cycle.
Of course the danger about moving things to the next release cycle is that the defects never get fixed. If you are going to mark defects as “acceptable” you need a process where these defects are continuously re-evaluated each development cycle, or even during the cycle.