Bugs, spiders, and priorities

Posted by on in Blogs

Steve Trefethen has been running a series of posts regarding the Delphi Development Process.  I thought I'd add a little salt to this post about how we handle bugs.  Then I started looking at some of my old posts and found that I'd already posted a rather long diatribe on how we prioritize the fixing of defects.  So rather than simply restating what I'd already said, I thought I'd provide a visual aid to explain my comments regard a defect's “surface area.”  I spent a few moments and created the following graph to illustrate this goofy idea I have regarding the use of a bug's “surface area” in determining its priority in the stack of things to be looked at. 

As you can see, by using a spider graph and picking various metrics that are the radial scales a quick glance at the data shows how much overall “surface area” a defect appears to have.  As I mentioned in my post referenced above, we don't actually spit out a spider graph for each defect.  This is merely a visual aid to help further illustrate my point.  Although, this may be a good thing to have our internal tools begin to actually provide....hmmm....  The number of metrics and their scales would probably be very different, but I hope this may help spark ideas, internally and externally.



About
Gold User, Rank: 83, Points: 11

Comments

  • Guest
    Lars Sondergaard Thursday, 7 July 2005

    Thats a really interresting way to look at it. A bug tracking system could show it as a numeric percentage and then bring up the graph on demand.

    Could be a pretty nifte new feature for StarTeam. Hope you will pass it on to StarTeam R&D.

  • Guest
    Erwien Saputra Thursday, 7 July 2005

    Allen,



    What does it mean by 'Type'? I assume that some type of bugs have more weight than others, can you please explain more what type has more weight than others?



    Thank you for the graph. I can see how QC votes works.



    For Code Impact and Overall Risk, are those reversed metrics? I mean, the biggger the impact, the smaller the area?



    Great post, I really appreciate it.



    Wien.

  • Guest
    Allen Bauer Friday, 8 July 2005

    Wien,



    I really didn't put much thought into the weighting the general interaction among the axis'. I was only trying to visually demonstrate what is currently a mental excercise, although I'd like to see this kind of thing put into practice.

  • Guest
    John Kaster Friday, 8 July 2005

    Sounds like something we should implement for QC stats. Easy enough to do. Of course, that means we have to start assigning values to the various metrics ;)

  • Guest
    Erwien Saputra Friday, 8 July 2005

    Allen,



    I think this is a very nice idea.



    I should read your post more carefully. I thought it was something that you are doing right now, I was so focused on the graph. :)



    Wien.

  • Guest
    Ralf Stocker Sunday, 10 July 2005

    Fix the bugs and bring more updates! Don't paint useless Powerpoint slides. Sorry ;-)



  • Guest
    Dan Miser Tuesday, 12 July 2005

    Absolutely wonderful post. I love the concept, and it be great to have that be a more formal part of the process. As a fellow developer, I know that http://www.borland.com/delphi" target="_blank">Delphi will never be zero defect, so all we can do is prioritize and fix the bugs that have the biggest surface area. Again, tremendous post.

  • Guest
    Bob Brunius Sunday, 7 August 2005

    Add to the metric the risk of making new bugs if you touch the code to fix the known bug.

  • Please login first in order for you to submit comments
  • Page :
  • 1

Check out more tips and tricks in this development video: