Fix it before moving ahead
rcozens at pon.net
Thu Mar 11 08:08:15 CST 2004
>>It shouldn't be a democratic issue...I think they
>>should _all_ be fixed.
>I don't normally quote the whole of another person's mail, but I
>agree so strongly with this that I really want it broadcast. I also
>think that the idea of voting for a bug to be fixed is deeply flawed
>if it doesn't take into account the severity of the bug, which can
>vary from an unimportant cosmetic problem in the IDE (the fixing of
>which might attract a lot of votes) all the way to a complete
Graham, Ken, et al:
Note that the two of you are _not_ saying the same thing:
Ken: "they should _all_ be fixed"
Graham "voting for a bug to be fixed is deeply flawed if it doesn't
take into account the severity"
My response to Ken's comments, as posted to improve-revolution:
>What good are more features if your user's application, or worse yet, their
>machines, crash because of a bug that should have been fixed by now?
Ken, et al:
Perhaps one reason why I have a lesser sense of urgency toward fixing
all known bugs before addressing any enhancements is that, AFAIK,
none of the known bugs crash my applications or the computers they
run on: the bugs relate to the Rev Dev environment, not to the
MetaCard runtime environment.
I can cause the development environment to fail in a number of ways;
however, I cannot cause my debugged standalones to crash. Albeit,
I'm not using QuickTime, any SQL interface, unicode, rtf or html
text, or doing CGI; but virtually nothing I've created in Revolution
is subject to engine-related failure at runtime.
So, while I agree that any bug that manifests itself at standalone
runtime and for which there is no easy workaround should be addressed
before enhancements, I can live with flaws in the Rev Dev environment
(eg: Rev 2.1.2 on Mac OS X hangs when opening a stack with a
breakpoint if it is already in debug mode), if the majority of Rev
developers feel completing some enhancement is more important than
squashing that bug.
On that basis, Graham, it seems to me you are closer to my position
then Ken's. In my original post to the thread, I opined, "And while
strict democracy should not be the deciding factor in what gets fixed
or added when, it certainly is an expression of where the user
community in general wants Revolution's resources focused."
Utilization of limited resources is, and probably always will be, a
sticky issue for RR Ltd. Would you prefer they make decisions in a
vacuum, on the basis of the level of vocality of individual users, or
via a mechanism whereby all users are offered the opportunity to
provide feedback on prioritizing all pending issues? Should an
obscure bug that knocks one developer dead in the water take
precedence over a less severe bug that 80% of developers want fixed?
Is it better to spend one person week fixing the one developer's bug
or five person days fixing five (or 10) less critical ones?
I don't know the "correct" answers to these questions; but I feel the
broader the base providing input to the Run Rev team, the better
their decisions will be.
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
More information about the use-livecode