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.
The desire to just fix "everything" is naive at best. It might work given unlimited resources, but nobody has those ... so you have to analyze the cost of fixing and the cost of not fixing and determine which is more costly, and then proceed on that basis.
ReplyDeleteArguably that's not something the crack programemrs ought to be doing, though; they should be fixing the bugs, because their skill at doing so well is in short supply. But that's also an idealistic dream.
Allen, I think you may have missed the point. The person who posted that comment was obviously frustrated with the track record of bugs in previous releases, and the schedule of fixes. The only reason I know this, is that I had the same reaction to your post, but I decided not to respond.
ReplyDeleteIt seems that in the past (and maybe still now?), a major version is released, and then all the developers move onto working on the new version, and only a tiny amount of resource is allocated for fixing bugs in the "previous" release, i.e., the one that customers are just starting to use. In the past, e.g., C++Builder, there have been lots of bugs, and few patches.
Fixing bugs in current-version products is very, very important to us (Borland customers). We use these tools day in and day out, and if there are problems, we are stuck with them (we don't have the source code, as you guys do!). The costs to us are process problems, productivity issues, etc.
I think your point is that there is an increased emphasis on delivering a quality product now at Borland. I personally appreciate it, and while I feel that it is a little late in coming, I for one do appreciate it greatly.
Tom,
ReplyDeleteThanks for taking the time to post. However, I think my comments are still valid. Who's to say that these ideas aren't going to be applied to existing defects? I mean, what if we were to add something like what I described to our existing tools, that contain the existing defects and suddenly started to see a pattern? Discussing new ways to look at data does not mean that we only look at new data.
Allen,
ReplyDeleteI think applying these ideas to existing defects is fine, but what would be more important is to get more resources applied to fixing (or hopefully preventing) them.
I don't think anyone can realistically expect that "all" the bugs get fixed, but maybe just "more."
The sniper analogy is fine when there are just a couple of issues here-and-there, but I don't think that has been the case in the past.