http://www.jrothman.com/blog/mpd/2005/05/even-unintentional-pairing-detects-defects.html Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk. Fri, 18 May 2012 15:02:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 http://www.jrothman.com/blog/mpd/2005/05/even-unintentional-pairing-detects-defects.html/comment-page-1#comment-130 Chip Patton Thu, 19 May 2005 18:11:55 +0000 http://jrothman.com/blog/mpd/?p=8151#comment-130 I'm going to generally disagree with you on this one. While it's true that developers create defects along with defects, it's not necessarily helpful to immediately label a perceived behavioral problem in software as a defect. This falls directly into playing the blame game and very quickly becomes political. Management in appalled to see 500 defects in a 6 month period; they are more understanding about 500 "trouble reports", "malfunction reports", "discrepancy reports", "issues", etc. Many issues reported by customers or testers (or anyone) don't end up being in the software proper at all, they are misconfiguration, documentation shortcomings, misunderstandings, environmental, etc. But once something has been labelled a defect in a software bug tracking system (the common name for such systems -- it's also just industry parlance; it may be euphemistic but it's not insidious), everyone tends to wash their hands of it, except the developers who are stuck with it. It is more helpful if it remains an "issue" and all parties help to understand its impact, source, repeatability and ultimate solution, which may or may not involve a software modification. Beware of inflammatory labels. Avoid the blame game and help everyone take the issues seriously. I’m going to generally disagree with you on this one. While it’s true that developers create defects along with defects, it’s not necessarily helpful to immediately label a perceived behavioral problem in software as a defect. This falls directly into playing the blame game and very quickly becomes political.
Management in appalled to see 500 defects in a 6 month period; they are more understanding about 500 “trouble reports”, “malfunction reports”, “discrepancy reports”, “issues”, etc.
Many issues reported by customers or testers (or anyone) don’t end up being in the software proper at all, they are misconfiguration, documentation shortcomings, misunderstandings, environmental, etc. But once something has been labelled a defect in a software bug tracking system (the common name for such systems — it’s also just industry parlance; it may be euphemistic but it’s not insidious), everyone tends to wash their hands of it, except the developers who are stuck with it.
It is more helpful if it remains an “issue” and all parties help to understand its impact, source, repeatability and ultimate solution, which may or may not involve a software modification.
Beware of inflammatory labels. Avoid the blame game and help everyone take the issues seriously.

]]>