24 hours of Delphi

Starting this evening at “oh hundred” hours (that's 12 midnight Pacific Daylight Time), the event of the year will be starting.  That is when the “24 hours of Delphi” event kicks off.  I'll be “on the air” at around 9:30am PDT and possibly again around 11:00am PDT.  I sure don't envy David I, Anders Ohlsson, and John Kaster who have to stay up and ramble on in order to keep the “dead air” to a minimum.  However, based on the schedule I've seen, there doesn't look to be too much of that, if at all.  Be sure to “tune in.”  I may decide to take some breaks throughout the day and “crash” their little party periodically ;-)..

Shotguns vs. sniper rifles..

No this isn't really about firearms, but actually a response to a comment I received regarding this post.  The comment basically chastised me (or Borland in general) that I (we) should just fix the bugs and release more updates rather than “paint useless Powerpoint slides.”  Wow.  I thought that was what we're trying to do (fix the bugs, that is).  The comment seemed to suggest that we should simply take a “shotgun” approach to fixing bugs.  I'm sorry but that is a foolish approach.  If you don't have and use tools to help you prioritize your work, you'll almost always be doing the wrong thing.  You can't prioritize based on data you don't have or can't see.  So rather than attacking the problem with a shotgun we get out the sniper rifle.  The surgical nature of using the sniper rifle approach reduces the collateral damage.

Oh, and again, that post was merely intended to be a visual aid to describe what is currently a mental process.  Powerpoint was not used in its creation.. Excel was ;-).  It was also intended to potentially spark some discussion externally and, probably more important, internally.  It seems to have done that since John Kaster has responded that maybe this should be something that is added to Quality Central.

Bugs, spiders, and priorities

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.