Gerhard Fiedler wrote:
>> The most successful projects (in terms of performance vs cost) were done
>> when documentation was kept to a bare minimum.
>
> I'd say that the most successful projects in this sense are where
> /everything/ is kept to the bare minimum needed to achieve the goals. The
> problem with this is not this simple (and rather obvious) rule, but the
> fact that when you are below the minimum in one area, the required effort
> in other areas can be much more higher than the economy in the
> below-minimum area. Finding this sweet spot of a global minimum is more an
> art than a science.

You must be an Agile convert already. :) From the Principles of Agile 
Software:

" Simplicity--the art of maximizing the amount
of work not done--is essential."

> I've probably seen more projects going down the drain because of
> insufficient documentation (and scope clarification) before starting 
> coding
> than because of excessive documentation. There are quite a few things you
> can (and should) find out before writing the first line of code (or
> thinking about components and circuit structures you're going to use).
> There are of course other things you'll only be able to find out after you
> have a first prototype, and trying to nail them down before is mostly a
> waste of time.

I used to think this way too, but a guy from Boeing said that the best thing 
to do is to dive right into the project, without any formal documentation. 
When you have a highly iterative and interactive environment, you discover 
problems and inconsistencies very quickly.

Of course, in a traditional programming environment where you have people 
isolated from each other, you need to spell out every single tiny detail --  
and even then you're not guaranteed a successful outcome.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist