--- Ken Wood <[EMAIL PROTECTED]> wrote: > How about the good old fashioned way: > > 1. A requirements specification that spells > out WHAT the software must do, without > ANY indication of how it should be done. > > 2. A design document that specifies HOW the > requirements will be met via a proposed > implementation. > > I suspect the reason we have so many proposals > in the form of code is that code is fun to write. > Specifications and design documents are NOT fun > to write. But, they are a better way communicate > a software effort than trying to compare multiple > proposals in the form of different codebases.
I second that (and is what I somewhat tried to do when getting Antidote off the ground). Plus it is much easier to debate over a single UML class diagram that a collection of 20 or so java source files. A high level class diagram would go far in helping the different proposals come to some consensus. sim __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
