>Curt writes:
>>As far as release plans go, I was having a beer last night with a
>>friend of mine working for a company producing software, and he
>>mentioned that they'd moved from sliding the date in order to get
>>the features in to sliding the features in order to make the date
>>(i.e., when alpha test time comes around, you drop features that
>>don't work, rather than delaying, and the same again when you
>>release). He said that productivity improved noticably, in part
>>because people felt more successful because regular releases were
>>going out on time.

>This is such a hard concept to sell to management, since it actually
>means that business plans are secondary to engineering reality.
>The only way I've found it possible to sell this scheme to upper
>management is to go to quarterly releases of predictable, small
>scale, changes.

Guess it depends on the management... :-)

We use both tactics.  In fact, the initial specs at the start of a
project are worked up with different rankings of features: stuff that
absolutely has to be there, stuff that is important, stuff that would
be good to have, but isn't totally necessary, and dream features that
are cool, but likely will never make it.

The hard features can move the date, if there is enough reason to do
so.  The softer features will get cut as the deadline approaches, if
necessary.

This also gives you good groundwork for where to start on the next
design phase when you ship a release: the features that didn't make it
into the last release.

-----------------------------------------------------------------------------
  Michael L. VanLoon                           michaelv@MindBender.serv.net
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------