
Don’t draw diagrams of wrong practices - edw519
http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/comment-page-1/
======
spolsky
I have been looking closely for years ever since someone wrote on Wikipedia
that I was an "advocate" of the waterfall method. There has NEVER been an
"advocate" of the method. Nobody has ever said that strict phase-by-phase
progression, with no possibility of iteration, is the right thing to do.
Never.

Waterfall has ALWAYS been an anti-pattern.

It has NEVER been a practice that ANYBODY advocated.

Yes, people started with design, then they implemented the design, and then
they realized there were mistakes in the design, and sometimes, stupid people
refused to admit this and change the design, and then they were called out,
and told that that "the waterfall method is discredited" or something like
this.

University instructors who "taught" the waterfall method were either grossly
misinformed (as if this was considered an accepted practice in the real
world), or, more likely, trying to make a point about the anti-pattern.

~~~
wglb
Perhaps you are unacquainted with the long, steady stream of failed enterprise
projects. Many of these were build with the waterfall as the primary model.
Should the project be successful, any "iterations" are called maintenance,
often staffed with deliberatly junior people, with little or no access to the
overall intent of the project. Maintenance is thought to be hideously
expensive in this context, and rightly so.

So you have worked for (MS) and built organizations that have a far better
idea of how to build software than the waterfall method, but believe that
there are advocates who believe in the waterfall way of doing things.
Fortunately it is becoming less frequent.

~~~
dschobel
Are there companies where maintenance & bug fixes aren't the domain of the
junior developers?

I've never seen otherwise unless the junior guys can't handle it and it gets
escalated to the people who are trusted with design.

~~~
run4yourlives
Yes. When maintenance is not considered something you do after you've built
the software, but a part of the evolution of said software, you regularly see
senior people fixing bugs and such.

------
audionerd
The "waterfall" method is comforting because it can be made to reflect a
company's existing physical/organizational structure: work passes down the
assembly line from Department A to Department Z and then it's done. And of
course we'll meet our deadlines, because look, here they are right on the
Gantt chart!

So the illusion of control I think is convincing, more so than any Royce
diagram.

~~~
spolsky
I have no idea where you got the idea that reflects a company's physical or
organizational structure. Not in any company I can think of. The most old-
school company I can think of, say, Ford building cars, knows that the very
process of building the factory will cause change in the design of the car,
and they know that they're going to iterate the design, at least annually,
which is something they've done since the 1930s.

~~~
audionerd
Ok, to call it the "physical/organization structure" was probably too literal.

What I'm getting at is what I've seen from waterfall, where responsibility is
"handed-off" from department A to department B to department C and then it's
"done".

Managers use the waterfall phases to schedule each department's workload, so
each team is essentially working in isolation.

e.g.: "Requirements and Design" is one department, "Implementation" is
another, "Verification" is yet another. (Design, Developers, QA)

~~~
LargeWu
This used to be the standard practice where I worked doing client web
development. Random Fortune 500 Company is not going to buy into an iterative
development process, because the person at the client company is usually some
peon with little real power to adjust budget or requirements as necessary.
That is, until it's too late, and their superiors are breathing down their
necks because the website doesn't do what they didn't say it should do. Plus,
if you don't use an iterative process, you can bill your client for massive
change orders.

So there's no real incentive on either side to change the process, unless both
companies "get it" from the start that you can't make quality software this
way. The likelihood of this decreases dramatically the larger the client.

------
sili
As far as I remember the waterfall model has been taught to us in Software
Engineering class in CS undergraduate degree as one of the most effective.
Even at that time I felt a little uneasy with it being so highly structured
and inflexible. In contrast I have not seen it being used even once where I
work. I feel duped.

~~~
harpastum
My SE class last semester also said the waterfall model was a fairly good
choice, although it "might not work especially well for projects with rapidly
changing specifications."

What they didn't say is that describes virtually every project.

~~~
derefr
I'd say they're right to teach it as such, though. Software Engineering is
about nuclear reactor software, traffic flow control software, car injection
system firmware, weather prediction grid software, lunar rover software, and,
just maybe (but this is at the borderline), ERP software.

Meanwhile, web applications (that aren't Google-search scale projects) don't
require _any_ software "engineering"—they're simply designed and then crafted,
more like a clay pot than a bridge. They're iterated like a play is rewritten
slightly after each performance, based on audience approval and obvious
errors, not based on any accepted theorem or body of knowledge that says that
the given practice is wrong.

A corollary of that statement is that Software Engineering has no use for most
of us here at HN :)

------
lmkg
I wasn't aware that the waterfall was really a "method" at all, much less
something that was taught. I thought it was an observation or model of the
sequential process that tends to spring up once you have specialized groups
within an organization. It's not exactly the absence of a development
methodology, but the process (if not the term) predates the idea of
development methodologies as a topic of concern.

