more vs. better (was Re: morning hack...)


Subject: more vs. better (was Re: morning hack...)
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 12 2001 - 21:48:15 CDT


At 08:01 PM 4/12/01 -0400, Dom Lachowicz wrote:
>>(PS. There is too much cool stuff happening right now! We should maybe
>>just finish off a couple features, get 0.90 and 1.0 done.)
>
>I view this as a damn good reason to postpone a 0.9 or 1.0 release
>indefinitely. There is a *lot* of cool stuff going on in the tree now, and
>I'm inclined to let it all keep happening (and make as much as possible
>happen as I can).

Oh dear.

There comes a point in every release cycle when this temptation rears its
ugly head. As soon as the dreaded "feature freeze" time starts looming on
the horizon, people start working really really hard to "sneak in" all sorts
of cool stuff that's not officially in the release.

Why? Human nature, I guess. It's a lot more fun to pioneer a new feature
than to do the hard painstaking work to hone and polish an existing one
until it Just Works, flawlessly. Sneak-ins are a *lot* more fun. :-)

But that doesn't make it right.

There's a direct conflict between "more" and "better" here. Too many of our
existing features are 60-90% complete, and until the rest of that work is
done, we'll never ship a 1.0 that meets both of the following criteria:

  - we can all be proud of it, and
  - millions of people love to use it.

Ask yourself which target you think those millions want us to shoot for:

  - N features that all work flawlessly, or
  - N + 5 features that all work pretty well most of the time.

The product we're collectively producing isn't a hobby, it's incredibly
valuable software that large numbers of people want to be able to rely on
for their daily use. We have a responsibility to those people to do our
best to give them something polished that they can use.

>A hurried 1.0 does not mean a good product... To quote the SG motto - "1.0
>isn't the end, it's the beginning." But I'd rather have a 1.0 with much more
>than they (or even we) had anticipated, and I think that our users would
>agree. 1.0 by year's end would be a good timeframe, IMNSHO.

Rushing 1.0 out the door would be a mistake, too. We have some serious work
ahead of us just to finish the current feature set, and then get a lot of
testing feedback to iron out any remaining glitches or flaws.

Opening up the flood gates to even more features just postpones this
much-needed work, and delays our eventual release indefinitely.

>To that effect, I'd be more than happy to release a 0.8.0 in another few
>weeks and begin a new development series - "0.8.0 - the road to 0.9.0". I
>don't like our current numbering scheme at all.

Are you proposing a Linux-style even numbered stable release that we'd
devote resources to maintaining as such? Is there a group of people willing
to create, support, and maintain such a release?

If so, how is that different from the old notion of 1.0 as the release where
we finish polishing the current feature set so it's rock-solid?

There's no getting around the fact that *this* work still needs to be done,
one way or the other. I'd love to see us focusing our efforts on making
interesting subsets of the feature/UI/locale matrices *totally* green,
instead of adding more red and orange rows and columns.

Paul,
designated grinch



This archive was generated by hypermail 2b25 : Thu Apr 12 2001 - 21:40:53 CDT