tag:blogger.com,1999:blog-3081442684129016822.post1187316501183719366..comments2024-03-02T14:14:58.495-08:00Comments on Manuel Klimek: Defects On Sale!klimekhttp://www.blogger.com/profile/04044731490885944160noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3081442684129016822.post-61887171878446636282007-08-29T09:07:58.000-07:002007-08-29T09:07:58.000-07:00Dave,thank you for your interesting links. I belie...Dave,<br><br>thank you for your interesting links. I believe that all you say is true.<br><br>I was trying to make a different point, though. I tried to extract the effect of one practice with regards to the defect rate and the expected cost of a defect.<br><br>I include the worst-case up-front additional cost for introducing a new practice in the coding effort factor. I use a worst-case defect-rate improvement to extract a pi times thumb number for the worst case cost of a defect for which the practice would be cost efficient /just by looking at it's impact on the defect rate/.<br><br>If it is already cost efficient when I look at the defect rate, then I don't need to look further. The effects I ignore can only /improve/ the practice's pay-off, this is why I ignore them - because I believe that in many environments a small impact on the defect rate alone improves productivity.<br><br>The interesting point you make is the idea of time-to-market. One could argue that this cannot possibly be included in the "worst-case" part of my crude model. On the other hand I don't yet believe that you really "loose" time to market with a lower defect rate, since most probably the customer will find some of the errors and demands that you fix them before going life.<br><br>Cheers,<br>Manuelklimeknoreply@blogger.com