waterfall (was Re: REPOST: Re: Book "python programming patterns". anybody read this??)

[Alex Martelli]

"Peter Milliken" <peter.milliken at gtech.com> wrote in message
news:a12t09$bai2 at news1.gtech.com...
    ...
> > > How can you BUILD something if you don't know what it is? If you are a
> >
> > By *finding out* what it is.  The process of "building", in the widest
> > sense of the word, is the process of finding out what is being built.
>
> And you don't call "finding out" requirements analysise? :-)

No, because, when the "finding out" process is finished, the end result is
generally knowledge *embodied in a working product*.  "Analysis" (even, I
presume, in your alternate spelling thereof) normally carries connotations
of omitting such equally crucial procedures as design, implementation,
testing,
deployment, documentation, training, tuning.  And yet, you aren't sure you
really know "what it is" until the various procedures converge and business
value is delivered (and only the customer is really qualified to judge about
this last and crucial point -- unless you manage to inveigle some customers
as at least part-time members of the team, you'll only get indirect future
indications of this, e.g. as filtered by marketing personnel who might well
lack other aspects of understanding).

For another potentially useful analogy on the subject, try reading
George Soros' "The Alchemy of Finance: Reading the Mind of the Market".

He doesn't write as well as he speculates (that would be a tall order
indeed), but there is one aspect of his thinking, as here expressed, that
makes the book relevant in this context.  He frames his speculations as
_experiments testing out specific financial theories_.  Understanding is
reached when a theory works (an investment makes money), and even more
when a theory is disproved (an investment loses money) -- yes, Soros is
an unabashed Popperian, and quite proud of it too.  Some others may be
better at verbalizing their theories, and rationalizing about them, but
"the process of building is the finding out of what is being built" holds
quite well here.  For example, such "details" (ha!) as edging-strategies
and fallback positions concretely embody the need to meta-understand:
develop concrete and detailed models, not only of what a theory predicts,
but of _how confidently_ it predicts it, and what follows from various
degrees of theory-failure.  Similarly, in software development, we may
adopt different flavors and intensities of "defensive programming" and
"flexibility-maintaining strategies/investments" that embody, not just
our best current understanding of what we're building, but also meta-
understanding about how confident we are of specs' stability and what
happens when (...not "if"...:-) the specs to slide along various possible
axes, or "fault lines", of variability.

I posted a few hours ago on another thread a similar analogy with the
works of Renaissance builder Biagio Rossetti (as opposed to ones who
were both great architects AND superb theoreticians, such as Palladio
or Alberti).  Studying the _process_ by which all of these greats of
the past reached their best results is somewhat enlightening, too,
although we must not forget that they were dealing with technologies
far older and more stable than Information Processing is today.  Hint,
anyway: if you think their masterpieces saw the light through a linear,
"waterfall" process of specification, then blueprinting, then bricks
and stones, then touching up... you are sadly mistaken here, too.  I
think (having never studied this in depth) that today, several further
centuries later, most building is probably "technologically stable"
enough to proceed this way, maybe -- most buildings being just about
identical to previous, already-existing buildings, and technology making
it prohibitively expensive to go for customization versus "one size
fits all".  But some very relevant buildings are still done the good
old way, with lot of interaction and feedback between "stages" that are
anything BUT separate.  Read, for example, the interviews Renzo Piano
gave back when his Kansai airport building was one of the few that proved
able to withstand the Kobe earthquake of 1995 "without so much as a
broken window".  He credits the input he received from the construction
workers (and took into account, iteratively revising design, etc) as a
major contribution to the structure's amazing robustness...


Alex