Rick McGeer <rick at mcgeer.com> wrote:

> 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.
Could you explain how you see this having anything at all to do with
documentation? I don't think I've seen anyone imply that you do all the
design and doc first and then write code and then stop. Design,
prototype, evaluate, retry is a crucial cycle but if you don't document
what you tried, why, the limitations and advantages... then you're
wasting everyones' time. 
> 
> 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.
Now you're being insulting to a long list of smart, capable and useful
people. There are _lots_ of members of a project team likely to be
unable to just look at your code and understand the broad architectural
meaning. Artists, doc writers, UI designers and yes, even marketing
people. Can you (plural non-specific you) look at a marketing plan and
work out what it means to the relative importance of different areas of
functionality? I can't. It needs documentation too.

> 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....
What! Now you're sounding like a barely graduated punk CS kiddie that
thinks only codeslingers matter.  


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
We can rescue a hostage or bankrupt a system, now what would you like us to do?