You are here

Increasing software quality: get rid of the bug list. Not! | Cypress Semiconductor

Increasing software quality: get rid of the bug list. Not!

I love to read Jack Ganssle, and his recent column is a great one: 
 
 
Jack Ganssle
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.


Jon Pearson
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

 

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.