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

[Peter Milliken]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:a0up6s$eef$1 at serv1.iunet.it...
> "Peter Milliken" <peter.milliken at gtech.com> wrote in message
> news:a0t49r$e861 at news1.gtech.com...
>     ...
> > 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
>
> The key concept in any form of modern software development methodology is
to
> acknowledge that you *CANNOT* confidently "get a step right before
> proceeding
> to the next": feedback and iteration are not optionals.
>

Agreed, depends on your definition of getting it right - that is why
feedback and iteration will always be with us.

> It makes about as much sense to describe this as "purely modification of"
> waterfall, as to describe communism as purely modification of the concepts
> found in liberalism (let each citizen pursue his personal advantage freely
> within the laws): sure, just change the laws so you can only do what the
> Central Committee tells you to do, and there you are.
>

Well, I think "looser" on this one than you do :-) Software development is a
stepwise process of determining requirements, producing a design, coding to
that design, testing the code and delivery to a customer - the ultimate
model :-). How you break that up or organise that for the particular project
is what spawns the so called "models". I don't know of any model that
doesn't have this basic process embedded in it.

> > 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 :-)
>
> How do you KNOW that "the customer's requirements are definitive"?

How can you BUILD something if you don't know what it is? If you are a
software house then you have to get an agreed contractual basis as to what
you deliver - otherwise you are always changing what you deliver - which is
fine if you are paid on a time and materials basis but not many customers
want to enter into that kind of open ended arrangement. So, just like hiring
a plumber to do a job, you ask for a quote, he asked you what the job is and
then advises the quote based on what you tell him - same thing has to happen
in software otherwise you go out of business backwards. Of course, if you
have the "luxury" of developing for an inhouse part of the company then you
(the supplier) and the customer can screw around to your hearts content
until one day a manager somewhere notices the dollars disappearing into a
blackhole and cans the entire thing (or makes the pair of you stop screwing
around! :-)).

So nailing down the requirements is always the first step - agreement means
that (at least at that moment :-)) when the customer signs on the dotted
line everyone believes that to the best of their knowledge the requirements
are definitive enough to proceed to build the product. The majority of
failures that I have seen and read about have one underlying common thread -
the requirements were still being changed at the time the project was
cancelled.

>
> Let's say: use waterfall when you are ABSOLUTELY certain that the
> customer's requirements are definitive and you have understood them
> correctly and completely at once.  To make "absolutely certain" more
> concrete, let's say that you will undertake to disembowel yourself
> ritually if it turns out you were wrong -- that the requirements were
> NOT quite as clear, well-communicated, well-understood, definitive and/or
> nailed-down as you thought.  If you're not willing to commit to this,
> then you're not ABSOLUTELY certain, and you shouldn't use waterfall.
>

I think you are getting too rigid here - all software models are based upon
the fundamental steps of requirements analyise, design, code and test. Even
models based upon rapid protyping follow the same basic steps (the
requirements are very loose obviously, the aim of protyping is to refine
them) - the protype is built to a set of understood requirements, the
protype has some form of design, there is coding and there is testing.

ABSOLUTE has to be applied if you want to stay in business - if the
requirements change (as they will) as the project progresses then the
customer can ask for a modification and project management deal with it i.e.
estimate cost and schedule impact, determine in conjunction with the
customer where and how the change will be slotted in i.e. it might be agreed
that the change can be progressed AFTER the current system has been finished
and "sold off" or the decision might be to fit the changed requirements in
ASAP.

So I am getting confused by your responses - all you seem to do is blast
waterfall - I haven't seen any attempt at some constructive response here, a
proposal for some other model because it fits better into your concepts of
software development or personal situations.

All I have said is that waterfall can and has worked in the past and
shouldn't be dismissed upon the argument that "it hasn't worked in the past,
so therefore lets not consider it" (my interpretation of your responses).
This seems a nonsense argument at best.

> Now THIS seems a workable operating definition to me.  Besides, the
> few developers self-assured enough to operate this way will soon be
> out of the gene pool, enhancing the breed.  A win-win proposition.
> The only real defect of waterfall as applied over the last few decades
> is the lack of a precise definition of "absolutely certain", and by
> the hara-kiri clause I think we remedy that quite effectively.
>

To me, the gene pool just seems to swirl and swirl with no signs of reaching
any superior state. It appears more to me that the new genes entering the
pool from colleges every year think they are the next Leonardo Da Vinci of
software development, that they can ignore the lessons of the past and just
stride out there with supreme confidence that they know what is right -
hence people like me (who have been here for several decades now) see the
same mistakes being made time and time again. I am sure that you are just as
confident as I am that you "know what is right". I have seen what works and
what doesn't, I don't pretend that I know it all, but what I do know is
correct for the circumstances I have experienced :-). So waterfall can and
does work in the right context. So do the other models - there is no single
model that will work best for all circumstances.

So, unless you are "absolutely certain" then I hope you are on a time and
materials contract, otherwise there will be a win-win situation and the gene
pool will have one less participant :-)

Peter