Now here's an idea...

[Steve Owens <uso01%eagle -at- UNIDATA -dot- COM>]

Eric (ejray -at- OKWAY -dot- OKSTATE -dot- EDU) says:
> [...he saw this on the cello-l mailing list...]

>> By the way, one clever fellow had a pretty good solution for [having a
>> program which doesn't do what the users want]: write the user's manual,
>> in as much detail as possible, before starting the design of the tool.
>> You can't be influenced by the inner workings, which you don't know yet,
>> and you can pass it around for criticism.

> Now, doesn't this sound familiar? Takes our conclusions a couple of
> jumps farther. Actually, it sounds like a reasonably feasible idea,
> within reason. I haven't met many programmers who would admit to not
> being able to code anything.

        I don't want to shock anybody (particularly not the programmers :-)
but this is actually the RIGHT way to put together a software package.  Check
out Frederick Brooks' _The Mythical Man-Month_, and various other software
engineering.  Also check out usability articles and essays.

        Theoretically, what happens is:

1) Somebody in the company decides a software package is needed.

2) Somebody (the programmers, the managers, the marketers, whomever)
   writes a document describing the needs the package will fill.

3) Somebody (the programmers) writes a specification that describes
   how the package will fulfill those needs.

4) The programmers go off to write the program, and the techwriters
   go off to write the documentation, both using the specification
   as a guide.

5) Inevitably, the program diverges a little from the specification,
   because the programmers found one way was too hard, or another way
   was a little easier.  The techwriter tweaks the documentation to
   match the program while the program is going through testing and
   prerelease stages.

        Of course, just because this is the right way doesn't mean it's
often done this way... sigh.

Steven J. Owens
uso01 -at- unidata -dot- com