David Putman

″We have separate analysis, design, coding and testing departments and most projects follow the corresponding phases in a more or less standard waterfall pattern″, said Jim, the operations manager. ″It mostly works well but we do tend to find a lot of defects at the testing stage and because of tight schedules we often have to ship before the defects are fixed, supplying patches to the customers later.″ It was no surprise to hear that the company was rapidly losing its reputation and its customer base. The sales and marketing department were constantly complaining of abuse and ridicule from the customers during contract negotiations. In response, as I often do, I drew a little picture of a project timeline, from project inception to product delivery and asked him, ″Where on this line would you least like to discover your defects?″ Occasionally, a respondent may claim that he never likes to find defects anywhere but the overwhelming majority say, ″Just before product delivery″ as did Ji

The problem is not the defects themselves, although, admittedly, they are a problem. The problem is recognising where the defects come from and what causes them, I′ve found that opinions on this subject can differ quite widely. For example, I once worked for a boss whose argument was that defects can only ever come from a programmer. For him there were no two ways about it, only programmers wrote code and so only programmers could create defects, in his mind defects were a problem for programmers and programmers only. He believed the one and only cause of defects was bad workmanship on the part of programmers and even proposed a league table so we could identify (and remove) the worst offenders. The funny thing is, this same company had a very strict recruitment policy, putting candidates through a long interview process and quite extensive technical tests so they only took on the very highest calibre of developers. I would be surprised if more than one in a hundred applicants actually