One reason would be that you're working at a company where management, 
salesmen and support need to know what's going on and have their saying 
(which is a good thing) and everybody can't read code. Calling everyone 
who can't read code incompetent is a pretty arrogant, nonproductive 
attitude.
Another reason is that you tend to get more emotionally attached to 
code than to brief descriptions which is inherently bad early on in the 
production cycle.
I'd say that a lot of techniques from the good (why bad?) old days 
tends to be forgotten while chasing the latest trend because humans 
like to simplify things, this good = everything else bad.

/Adde

On 2004-10-15, at 22.33, Rick McGeer wrote:

>
> 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....
>
>
>
>