Cyrus Blather Recall class | bar stools

Cyrus Blather Recall class | bar stools — Fri, 19 Jun 2009 09:29:59 GMT

PingBack from http://barstoolsite.info/story.php?id=1362

re: Recall class

AndrewSeven — Fri, 18 Mar 2005 14:22:00 GMT

For a beta, that problem would be ok, after all it encourages you to use polymorphism instead of switches ;)

I'm only using Beta1 at home, but so far I haven't noticed anything near that level.

Off topic : When you type a method name that doesn't exist, there is a smart tag thingy that appears to generate a method stub.
Is there a way to generate a property stub the same way?

re: Recall class

Jeff Atwood — Fri, 18 Mar 2005 04:29:00 GMT

Your "hypothetical" examples are scaring me.

re: Recall class

Steve Hall — Fri, 18 Mar 2005 00:41:00 GMT

For the above hypothetical example, I would expect that such a "trivial" bug to be "prevalant". I.e., the MTTF (mean-time-to-finding it) would be hours after the beta gets posted on MSDN. And it probably wouldn't be just a single user...

I think the problem here is the terminology you used to categorize the problem: "trivial". I don't think ANY user would classify such a problem using that word when they encountered it. (I can think of other more crass swear words though...) The risk assessment must be more objective than using flippant (and emotionally charged) words like "trivial". In short, your idea of trivial is not going to be another person's definition. Stay away from using those kind of words!

In good problem tracking systems, there should always be two separate rankings: priority and severity. In fact, IBM codified severity ranking decades ago which has been in use in thousands of data-centers for over 30 years: 1=Severe, 2=Serious, 3=Moderate, 4=Low. Most data-centers added a 5=Wish-list to account for problems that would be "nice to solve at some point in the future". (Note that IBM published very explicit definitions in the '60's to ensure that all customers were in sync with them and these definitions are still in use for all their software and hardware problems.) The priority ranking would go from 1 to 4 or 5 to indicate the order in which problems were to be diagnosed and solved. Typically, priority 1 problems would be solved first, and in ascending severity order. .E.g., priority1/sev1 problems solved first, priority1/sev2 problems next, etc.

Given the above scheme, the above hypothetical problem would be ranked severity 2, since the app. completely fails (but can be circumvented). (If the app. failed repeatedly and there was no circumvention or work-around, then it would be severity 1. "Sev1" problems are those that are an "outage" and require vendor-intervention.)

Essentially, the severity ranking quanitifies the prevalance of the problems, i.e,. how many customers are likely to encounter the problem and the resultant "outage".

If for instance, the IDE were, instead of failing, to display an error and continue running, then that would be a severity 3 problem since the application recovered. Only if the IDE were to recover from the erroneous error state and resume running WITHOUT functional errors, could it be expected to be termed severity 4...which could be called "trivial".

The above hypothetical error is certainly NOT severity 4 (what you're calling "trivial").

Now some have argued over the decades that severity should be broken into it's two determinant components: prevalance and error-result. And some problem tracking systems have actually implemented that. But, experience has shown that a dual-ranking is sufficient for most problem domains. A tri-ranking problem domain introduces more complexity in arguments over whether the sort-key (order of problem solving) should be priority-prevalance-errorresult or priority-errorresult-prevalance.

Now getting back to the notion of a beta recall, you need to decide what the pain-threshold is for back-tracking to fix embarassing seemingly "trivial" bugs. This is why you should have priority ranking system in place. Then it becomes simple to define a recall rule like this: Recall a beta if any priority1/sev1 bugs appear within the first 3 days after release. For the above hypothetical case, even though the bug could be classified as priority 1, because it's a severity 2 problem, it wouldn't trigger a recall.

Note that I've written a half-dozen large-scale problem tracking systems (and SCCS's that were integrated with them), and have observed such dual-ranking systems proven to satisfy the needs of large-scale software (and hardware) bug resolution. (I.e., Both OS and computer hardware development.) The biggest problem encountered with problem tracking systems (even with ranks to help dictate the order of problem resolution) are the politics of fudging the rankings up or down to change the sort-order to satisfy whichever project manager or product manager is screaming the loudest. Having numeric ranks helps to keep all the stake-holders honest, since each rank is quanitifed. Problem tracking systems that use words for the ranks always end up with squabbling over what the words mean...just as I pointed out with your use of the word "trivial".

Hope this helps! (Think objectively. Use dual-ranks. Use numeric ranks.)

re: Recall class

Cyrus Najmabadi — Thu, 17 Mar 2005 19:35:00 GMT

Andrew: So it would be worth recalling a beta (which is expected to have bugs), in this case?

And just because something is trival doesn't mean it should necessarily get fixed either. As i mentioned, it's a combination of factors. If we kept on fixing trivial bugs then we'd never get the beta done. *ever*

re: Recall class

AndrewSeven — Thu, 17 Mar 2005 13:02:00 GMT

"So is this recall class? It's just not clear."

Yes, absolutely.
How could you be expected to be taken seriously if the system fails on something so trivial.
Just imagine whast they would say on slushpot err I mean slashdot.