On Wed, 30 Jan 2002 Ben Rubinstein <[EMAIL PROTECTED]> wrote:
(big snip)
> During this period I spent a quantity of time wrestling with the Geometry
> manager; and then some time exterminating it from my stacks. I did try to
> track down the details of its misbehaviour but it was getting sticky, so
> rather than spend more time on something Rev team might already have known
> about (that's the value of an accessible bug tracking list, which is a
> separate discussion) I sent a note which said that I thought it was
> substantially screwed, and if they thought otherwise I'd put some more work
> into reporting it. They didn't ask for more info, I left it.
Which I think emphasizes my point about needing to get reports rather
than stiffling them. Even if there wasn't a bug, the fact that you
even struggled with it for more than an hour or two IMHO makes its
existing behavior worthy of a bug report. Without a stream of these
kinds of reports, even their doc people don't know that there is a
problem in this area. Of course, with these kinds of problems, it's
especially important to send in an example stack, but it sounds like
you already had one of those, making the additional work required on
your part minimal.
> Now, your suggestion is that with each new release I should be diligently
> putting all the Geometry Manager settings back into my stacks to see if it
> messes up again, and then removing the data if it does, on the off-chance
> that it has been worked on but that the improvements haven't been mentioned
> to customers.
This again gets into an area of expectations. You seem to have low
expectations that a problem you have reported will be fixed in the
very next release. I think if you raised them, you'll not only not
waste time, but will in fact become more productive in your own work
as well as becoming a more valuable partner for the vendor.
> > Finally, and most importantly, anyone who *doesn't* report a bug
> > because they read about it in a README, or worse, doesn't actually
> > verify that a bug they have reported is fixed in a new release
> > regardless of whether it's listed in some README, is making a huge
> > mistake, and is almost certainly a causal factor in *decreasing* the
> > overall quality of the product. We, like all software developers I
> > know, live or die by the quantity and quality of bug reports that we
> > get.
>
> Not to keep repeating myself, but putting in a good quality bug report takes
> time. If I can't judge whether that time is wasted, I'm less likely to
> spend it. The result is reduced quantity and/or quality of bug reports for
> Rev/MC, not increased.
I agree that some bugs do take hours or even days to even come up with
a reproducible example for. And it's very tedious work too.
Fortunately, most aren't this bad, and just sending the stack and/or a
simple recipe is sufficient. And even intermittent problems are valid
subjects for reports. I'd much rather have a lot of reports with just
"It crashed when I was opening a player but I can't reproduce it" than
nothing. At least then we have information about where to concentrate
QA work.
Also, if we can reproduce a problem, we can usually come up with
workarounds a lot more easily and a lot more reliably than you can,
offsetting the time you have to spend preparing the report.
(snip)
> I have torn my hair out debugging an impossible problem in CodeWarrior,
> before I turned to the read-me and discovered that there was a known bug in
> the code-optimiser which could cause my problem (that's one of the things
> that taught me to make diligent use of read-me's).
I think we probably don't want to use CW as an example of how to do
things. We've reported a lot of bugs to MW, and the only useful
pieces of information we've got out of them about fixes or workarounds
come from other customers (indeed, stuff that I wrote can be found on
their WWW site's FAQ section). MSL (the Metrowerks Standard Library,
which provides standard C-language features) in particular has caused
us more tech support problems than all other libraries we use
combined. And don't get me started on their debugger, which in the 10
upgrades we've bought from them has *never* worked right.
> Conversely some years ago testing found a problem with our installer,
> shortly before releasing a CD-ROM product. When we finally tracked it down
> to the combination of a particular (MS) mouse with a particular version of
> Windows, we contacted the installer company and found that they knew about
> it but had chosen not to tell their users (by definition, professional
> users) - in read-me or FAQs, until they asked. I immediately cancelled our
> licenses with this company and switched to their competitor, who we have
> used ever since. Not only did we waste our time trying to track down
> something that they knew about; we found it by chance in testing (that
> hardware wasn't in our config lab) and could easily have pressed 20,000 CDs
> with this bug, and without a read-me that would have told users how to avoid
> it, leading to a substantial potential increase in our support calls, which
> completely undermines the profitability of that kind of product.
Just playing devil's advocate here, but what do you think the odds
would be of them listing this fix in a README as something like "fixed
bug in install_openregistry that caused crashes on some systems".
Certainly the odds of you being able to extract anything useful in the
way of workarounds from *their* readme to put in your own are about 0.
Here is where expectations count: the problem here was the fact that
they would even *ship* a new version of a product with a latent bug
like this that they knew about. We never would (which is the big
reason why we don't announce release dates and switched to
subscription model licensing policy, both of which reduce the pressure
to ship a product at a particular time, bugs notwithstanding).
> CodeWarrior, BareBones, iCab are among the tools that I use, with very
> different scales of development teams, that include read-me's of this sort.
> Their products seem to improve substantially with each release. They don't
> seem to have been forced to cancel all development work in order to
> concentrate on generating release notes; nor do they seem to have lost
> customers. The survival of the products and companies has not noticeably
> been affected.
I don't know about the others, but I certainly wouldn't want to be in
MWs shoes about now. They *are* losing money on their MacOS and Win32
products, are getting badly squeezed by Apple's free tools, and many
of their customers (including us) are increasingly reluctant to
upgrade (in fact, if at all possible, CW 7 is the last one we'll be
buying). I don't think READMEs have much to do with it, it's more
their callous regard for support (with the exception of MWRon, who
IMHO, is the only really good thing about that whole company).
> MetaCard, and you personally, have an enviable reputation for customer
> support and responsiveness; which I think the RunRev team are living up to.
> I agree there are questions worth asking about running public bug lists,
> but I really think that proper release notes with each test release are an
> important feature of the Revolution package.
Agreed. Now we just need to strike the "proper" balance in their
contents ;-)
Regards,
Scott
> Ben Rubinstein | Email: [EMAIL PROTECTED]
> Cognitive Applications Ltd | Phone: +44 (0)1273-821600
> http://www.cogapp.com | Fax : +44 (0)1273-728866
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
