No Bug Database?

Posted by Deborah Hartmann Preuss on Sep 03, 2006

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Artifacts & Tools ,

Customers & Requirements ,

Debugging ,

Project Management ,

Antipatterns ,

Tools ,

Programming ,

Agile ,

Troubleshooting ,

Patterns

James Shore has written about a crazy idea: Get rid of your bug database. He's not advocating that teams ignore problems - exactly the opposite, in fact.

Bug databases are often a black hole of to-dos, packed with hundreds of questions, feature requests, and genuine defects. Who has the time or energy to slog through that mess? Shore thinks there's a better way, though not everyone agrees - there was some vigorous discussion on this issue on the C2 wiki this summer.

Perhaps it depends on what exactly that bug database is being used for.  Some of the reasons (good or bad) to use a bug database, mentioned by developers on C2, include:

• bugs reported by nontechnical people at times where there are no coders around
• Intermittent bugs
• bugs reported by multiple product owners and testing sites
• capturing a discussion about an alleged bug (e.g. it's a technology limitation)
• bugs which are integration-related and cannot be expressed by a unit test
• to allow customers, developers, manufacturing, QA, the field, marketing, et cetera to all share the same information
• Sarbanes-Oxley compliance
• development metrics over time
• "not only bug descriptions, but detailed reproduction steps, screenshots, crashdump data, movies, logs, callstacks, even references to code"

Shore acknowledges "Some bugs are too big to identify and fix immediately, and others are feature requests in disguise. For these bugs,  XP teams already have a way to prioritize and schedule work: stories."  Still, Shore proposes A Better Way to Fix Bugs (when you find a bug, fix it), A Better Way to Track Requests, and looks at How Can This Possibly Work?  Essentially, he proposes replacing the vicious cycle of the ever-growing bug list, hidden out-of-sight in a database, with a "virtuous cycle" that decreases the number of defects as team members actively take ownership of bugs in real time.

He notes that a team may, in fact, need to use a dedicated bug database - but then they need some mechanism for getting stories out of the bug database and into the release plan. He notes that when XP teams let bugs pile up, their prime metric, velocity, is falsified and release dates can be put at risk.

This "No Bug Database" article is part of a pre-publication review copy of Shore's in-progress book, The Art of Agile Development.  He's looking for comments, saying "As you review, remember that our aim is to make an intensely practical book that shows mainstream development teams how to adopt and use agile software development."

1. Back to top

   what about the stakeholders?

   by Alex Popescu

   If you follow the advise:
   

   When you find a bug, fix it.

   
   and we agree that some/many bugs are not immediate, than this may bring problems to the priorities established with the stakeholders. In this case, I guess they must be involved so that the priorities are re-established. But to involve them each time a bug is raised is not an optimal solution, so we need a way to keep the list of bugs around till the next prioritization session is scheduled.
   IMO this suggestion can work only with extremly small numbers of developers and stakeholders.
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.

   Reply

2. Back to top

   Re: what about the stakeholders?

   by Joost de Vries

   So, ehm, Alex, is the fact that I do not see my cursor typing this using Firefox a known bug with low priority or will you fix it right now? :-)

   Reply

3. Back to top

   Re: what about the stakeholders?

   by Deborah Hartmann

   Good points, Alex.
   
   For classic (small) Agile teams with a single customer representative, this just might be possible. But many teams (need to?) make compromises in the area of customer involvement, so delays are imposed.
   
   But I think you implicitly raise another point worth thinking about: is every bug of the same value as the feature work it displaces?
   
   For example: which is of greater value - seeing your cursor in this text box when using FireFox, or adding a site search? especially if the former is twice the work of the latter (I don't know if it is... but bugs can expand to take up enormous time). Which of these would a stakeholder prioritize?

   Reply

4. Back to top

   Re: what about the stakeholders?

   by Alex Popescu

   I would schedule at least an investigation of it, if you pass me additional info ;-].
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.

   Reply

5. Back to top

   Re: what about the stakeholders?

   by Alex Popescu

   The most interesting approach I have read about and that imo works best is the one described in FURPS+: each iteration must contain functionality, usability, reliability, performance, supportability and something more. Also keeping in mind that somehow the dev team is also a stakeholder, I consider that bugs must be considered with enough attention (and let's not forget that a long living bug is becoming more and more dangerous as the time passes). If you have smart customers, sometimes you can even schedule small size bug fixing iterations.
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.

   Reply

6. Back to top

   Re: what about the stakeholders?

   by Joost de Vries

   It's surprisingly difficult to edit comments when you can't see the cursor.
   I experience the effect using Firefox 1.5.x (most recent) on Windows XP.
   Cheers.

   Reply

7. Back to top

   Re: what about the stakeholders?

   by Alex Popescu

   Joost, I am on FF1.5.0.6 and I cannot reproduce the problem. I have also tested it with FF1.0.x and even FF2.0b2 and still no luck. Don't know what to say.
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.

   Reply

8. Back to top

   Re: what about the stakeholders?

   by Joost de Vries

   I don't know what to say either. I experience it on 2 separate machines.
   Maybe it's got to do with a plugin I use on both machines...?

   Reply