Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsh!wcs
From: wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
Newsgroups: comp.unix.wizards
Subject: Re: Ware Ware Wizardjin
Message-ID: <1991Apr12.233838.27407@cbnewsh.att.com>
Date: 12 Apr 91 23:38:38 GMT
References: <9104072151.AA28702@gaia> <9104081805.AA14112@samadams.Princeton.EDU> <63660@bbn.BBN.COM>
Organization: News Busters
Lines: 46

In article <63660@bbn.BBN.COM> adoyle@vax.bbn.com (Allan Doyle) writes:
]but there are still *new* models every year. How do they do it? They
]use a design pipeline. While Design A is in production, Design B
]is in retooling, Design C is in prototyping, Design D is in concept ..
]How many companies do this with software? I suspect it is near heresy
]to suggest that a SW company begin design of a new rev of software using
]new technology before the previous rev is out the door. Look at how

In the traditional top-down methodology for large software projects,
this is done all the time.  The project isn't done just by hackers,
it's got market-analyzers, requirements-writers, system-designers,
system-engineers, code-writers, system-testers, etc.  
If the project is big enough to need lots of people, when the
requirements-writers get done writing the requirements for version N,
they start writing the requirements for version N+1. 

One big problem with this approach is lack of feedback.
You never really understand the problem at the beginning.
You might make a bad design decision early on, but you can't tell
until you learn the things you learn by implementing pieces of the
system based on that design decision, which may be much later.

This is why things like prototyping are critical, and why
military systems ALWAYS have cost overruns - the procurement process
forces an extremely rigid formal design system, without much feedback,
the people who evaluate the initial phases tend to be bean-counters 
who don't understand the implications of the decisions,
and it's easier *contractually* to try and implement an atrocious design
than to go back and fix the initial decisions - especially if the
bad decisions were requirements written by the customer.

If the design cycles are too long, there's often no way out -
except the Mythical Man-Month solution :-) of more and more bodies.

But if you've got a clean development process with a small core of
good people who know the whole system, you can still do pipelining.
Most large systems have a basic capability with a lot of modular
features built on top of it.  Typical things you do in later
releases are to add features that didn't get in Rel. 1, and to make
the core system go faster or add capabilities while upward-compatible.
If you do it well, this can all go on in parallel.
-- 
				Pray for peace;		  Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.