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

[Peter Milliken]

Thanks Gordon :-)

Yes, what is described is "waterfall" - I object violently (:-)) to the
concept that it "didn't work" though. Seems to me that there is a lot of
"well it didn't work for all situations so there must be something wrong
with it" thinking around the place - waterfall works very well in many
situations - but not all, there is *no* definitive model (to my knowledge
:-)) that works well in *every* situation. In fact, waterfall has worked
very successfully on some extremely large projects - waterfall was the
"standard" for many years in defence contracts - sure there were some
absolute disasters but there were also many resounding successes - in fact,
I would suggest that analsise of the disasters would many times show that
the waterfall model wasn't adhered to i.e. I worked on one project that went
for 7.5 years and was cancelled by the customer - they were still changing
the SRS when the contract was cancelled - doesn't matter what model you use,
it is very hard to hit a moving target.  So there are "many decades" of
industry experience that show it did work extremely well. The limitations of
the model are well know though and hence the rise of other models such as
spiral etc. I won't bother to go into the why's and wherefores these are all
adequately covered in software development textbooks.

I would just caution both of you to be a little less dismissive of waterfall
(sorry Gordon, I don't think you are being dismissive of it but the
"background" of waterfall that you give is wrong - in my experience :-)) -
the concepts are still sound. As far as I am concerned the other models are
purely modifications of the concepts found in waterfall (get each step right
before proceeding to the next) and whether you use waterfall, spiral or
whatever is purely a question of judgement or trade-off for the situation
you are developing for.

AFAIK, waterfall is perfectly appropriate if you can get your mind around
the problem in one go and the customers requirements are definitive - use
one of the other models otherwise :-)

Peter

"Gordon McMillan" <gmcm at hypernet.com> wrote in message
news:Xns9188626EA5C2gmcmhypernetcom at 199.171.54.213...
> Alex Martelli wrote:
>
> [snip]
>
> > This is also known as the "waterfall model" of software development.
> >
> > It just doesn't work, as many decades of industry experience have amply
> > shown.
>
>
> The "waterfall" model comes from the days when most development was
> mainframe batch systems. It "worked" (to some limited degree) in that
> environment because of the following conditions:
>
>  - there were only a half-dozen or so basic building blocks in mainframe
> batch systems (sort, merge, select, extract...)
>  - the scope of the projects (successfully managed through "waterfall")
was
> generally tiny compared to the scope of the system in which they fit
>  - there were senior people on the project who could balance the "top
down"
> with some "bottom up", but keep it secret
>
> Violate any one of those (too many technical choices; too big a system; or
> people who aren't very familiar with the system's context) and the
resultant
> system was iteration 1 of an iterative prototype too expensive to
complete.
>
> More generally, you could describe a successful "waterfall" project as an
> iterative prototype that worked the first time through.
>
> What Peter had right was that *thinking* about the problem is always
> necessary, even in an iterative prototype :-).
>
> -- Gordon
> http://www.mcmillan-inc.com/