I love to read Jack Ganssle, and his recent column is a great one:
3/21/2011 1:57 PM EDT
Teenagers can learn only from their own mistakes. That seems true for a lot of software types, too.
Jack Ganssle asserts that since a Capers Jones study of late software projects showed that bugs were the biggest cause of late delivery, get rid of the bug list. This isn't as crazy as it sounds when you consider his justification that no one knows how long it takes to fix a bug, so there is no believable schedule when you have a bug list. To fix it, get rid of the bug list.
The (real) problem is NOT that you have a bug list, but what you do with it. For instance, if an organization has quality as its charter and is producing software, every reported defect is a quality "escape" and should be investigated. Great, where is the extra team to do this? Exactly. If software quality is the goal, you cannot rely on the developers alone. You must engage a quality team (and yes that does have two meanings).
I mentioned this a couple of posts back, when I cautioned "you get what you measure" for good and bad. If you make your goal a low number of defects (the length of the bug list) as the measure of product quality, in and of itself, you will get fewer defects reported, but not necessarily higher product quality. Similarly, if you measure productivity of the "quality" team by the number of defects reported, you will certainly get a high number, but again, in and of itself, a measure of nothing. So what is a bug/defect list for? As Jack recommends, should we just throw it out and replace it with a commitment to solve bugs as they appear?
NO! Emphatically NO! A bug list CAN become a driver of quality, and if this is the desire AND a firm schedule for the development is also desired, then put a team (may be one person to start) in the role of Bug Detective. Is a new feature or enhancement reported as a "defect" (pretty typical)? Then the bug detective would investigate the source of this new feature, why marketing/product definer didn't include it, and MOST important, how to avoid the "defect" next time. Did a test fail? Why, what caused the failure and based upon the source, dig deeper until the root cause is found (NOT schedule, real work/task that was forgotten or omitted) and to increase quality, what is to be done different in the future. Did a failure get reported from the field? Why wasn't it caught in a test, AND why did the bug occur in the first place?
In a sense, Jack's recommendation is good: To increase the quality of your software and the predictability of project schedule you must eradicate the bug list, by driving the number of bugs to zero. If you have a product with hundreds of bugs reported and captured in a bug list, you have a product of unknown quality; it isn't high quality, but you cannot know how low the quality is with a big bug list. Stop and take back control of your project.
Methods and Madness, March 27, 2011
Happy Birthday Quentin Tarentino; living proof that dropping out of school after 9th grade and working in a video store can be a viable career development path