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.
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.
ReplyDeleteCould be a pretty nifte new feature for StarTeam. Hope you will pass it on to StarTeam R&D.
Allen,
ReplyDeleteWhat 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.
Wien,
ReplyDeleteI 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.
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 ;)
ReplyDeleteAllen,
ReplyDeleteI 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.
Fix the bugs and bring more updates! Don't paint useless Powerpoint slides. Sorry ;-)
ReplyDeleteAbsolutely 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 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.
ReplyDeleteAdd to the metric the risk of making new bugs if you touch the code to fix the known bug.
ReplyDelete