Re: [RE: emc really needs a copyleft cad/cam package]

[Anne Ogborn <anniepoo-at-netmagic.net>]

>  As you mention design needs to go first, although code can often
> serve as the operational definition of specific features. 

Code is not and never will be a design. 
I suspect you are saying one of two things - 
Either you're saying "well, here's some code that works, so we don't have to do a design for
this part" - which is an awful way to build a system, or you're saying This:
  Once I was part of a project which was orginally estimated to last 2 years. When I came on, 
they had been at the project 2 years, and current estimate was to ship in another 6 months.
I soon discovered that they had spent the 2 years "designing". They had paper descriptions of
every method and every variable. What they didn't have was code.
Naturally, in 6 months they did NOT have a working system.
My experience has been that once the function of the program is well defined in a UI
spec, the engineering spec can be a reasonably short document, simply because the necessary
design patterns become obvious.

It can be useful to build functional prototypes,
although even that process is often dangerous. Most dangerous is that the
prototypes often fail to be discarded. Also dangerous is that the work of making
a functional prototype makes the person who wrote the prototype have an investment
in seeing that design implemented.  Also dangerous is that competing design ideas
look less good because a paper demonstration is less appealing inherently than a
program one can fiddle with.

One real problem with the "code first, document never" mentality for an opensource
project is that the code becomes completely opaque to all but a small group of
insiders. Soon other users, even those who can code, stop modifying the code and
start asking the core group to do it. The core group can't respond to all the requests,
and the system breaks down.
The business of RS274 /HPGL/... is a classic example. Realisticly, the person who
writes the output generator module for the "WhizzyMill 5000" will almost certainly
be somebody who owns a WhizzyMill 5000 and wants to use our program to make code for it.
Open Source works because the source is open. Let's encourage contributions from
"outsiders". The way to do that is to have well designed, well documented code. 

>  Don't close up
> the design to quickly or good features get left and evolution gets boxed
> in.
> 

Yes, and I've found that no software design is all that much like what
gets finally built. That's not a reason to do the design.

OK, hope nobody out there feels I'm being too strident about this. It's just that I've
been through this with 18 different large systems. This will be my 19th.

Annie