Giovanni Giorgi wrote:

> I  cannot agree to this.  The correct statement in my humble opinion 
> is "Coding is *poor* design", at least in software for production 
> environment.
> I find difficult to do a continuous coding and to leverage it to a 
> good design, *when* the driving force is a strong marketing, and you 
> cannot count on stable specs and so on.

Well, each to his or her own, I guess.  In my case, it's not opinion or 
belief.  I've tried both, know which works for me and why.  Exactly why 
it's easier or more useful to write  a document or UML diagram than a 
working, instrumented prototype has never been clear to me, and I  know 
that document- and diagram-heavy "waterfall" projects I've been on took 
forever to finish, whereas when I got to do it my way (understand the 
problem, bring something up, understand better, modify the code, etc...) 
we both got done faster and had fewer bugs.   It was the observation 
that running a tight cycle of design, code, and test was far more 
productive that led me to question why, exactly, this was the case.

Which led to the insight about dynamic artifacts, etc.

A better question is WHY we believe that writing papers (as opposed to 
code) is design.  A cynic would argue it's because incompetents want 
designs explained to them in language they can understand.  A nicer 
person would argue that our "software engineering" (hate that phrase) 
techniques come from the bad old days of time-shared batch, when a tight 
design-code-test cycle was difficult....