
What was your experience with Waterfall development? - aerovistae
I&#x27;m young enough that I&#x27;ve only ever been part of Agile companies, but my slightly older coworkers all have horror stories from the days of Waterfall. I have trouble understanding.<p>What was so bad about it? Or, contrarily, what did you like about it?
======
AnimalMuppet
The feedback loops were too long.

Real-world waterfall always contained the idea of feedback from later steps
changing the results of earlier steps. (Not having this means you have to be
essentially perfect in your earlier steps to avoid having garbage input to
your later steps. That can't be done. What's more, circumstances change during
the life of the project, and if you don't respond to that, you're programming
for the world as it existed six months or two years ago, and that is a recipe
for failure.) This feedback to earlier layers was considered entropy, and the
task was to manage it, to keep it from running out of control. The result was
that you could be implementing something a year after the requirements were
done, and six months after the design was done, and if you saw any problems,
you were supposed to not revise the design (still less the requirements)
unless you really had to.

In contrast, agile wants to have those times as short as possible, and to feed
what you discover during implementation back into the design (and even
requirements), in order to get them to better conform to reality.

Real agile is all about keeping the feedback loops tight. Waterfall was all
about wholly completing phases, in order. This lead to waterfall being rather
unresponsive to new information or external changes. (To see how demoralizing
this can be, imagine working to implement something, where for the last three
months you _know_ it's the _wrong_ thing.)

------
matt_s
The delivery aspects of waterfall usually means it is a rigid and structured
organization with people in rigid and structured roles that have defined
responsibilities.

This can drive bad behavior, pitting teams like requirements analysis, design,
development and test against each other since they sometimes have competing
interests.

In a larger organization, competing interests emerge since these teams are
often managed by separate people who manage and measure their people with
objectives that are for the role. People who write requirements get focused on
common ways to document requirements, templates, etc.

A rigid organization using waterfall tends to have very structured, approval
oriented deployment processes which leads to things like only having project
launches _3 times per year_. A weekend launch starting with a backup of the
system on Friday in case they need to restore Sunday night if the long
sequence of 300 deploy steps is somehow botched.

I went from organizations like above into one that uses a Continuous Delivery
model. This means we deploy every day, multiple times a day if needed - to
production. Small changes that are testable with builds being tested
continuously, operations of the environment heavily monitored and developers
own their changes into production.

------
d--b
I think the main issue with waterfall development was the corner cutting at
every step. Because software is not as hard to modify as hardware projects, it
would be faster to do a shitty waterfall plan where the requirements would not
be completely understood, and the implementation design lacked some major use
cases, and implementation would miss other things like error handling, and the
final product would be crap needing fixing.

The issue is that it would be cheaper to do it that way, because trying to get
all requirements right and implementation right before doing was really
expensive and still incorrect in he end. You'd always end with bugs or missing
features...

------
Jtsummers
Waterfall means at least two things. I'll assume for my answer that it means
only one of two things which I'll discuss.

All development process models assume the following tasks:

    
    
      Requirements collection
      Analysis
      Design
      Development
      Testing
      Deployment
    

After the first iteration, you move to maintenance. The only difference for
maintenance is that "requirements collection" is more focused on collecting
problem reports and change requests. Most of the requirements are already
established.

Waterfall:

One meaning, the original and literally the worst thing ever, is that each of
those activities is completed essentially in whole before the next and without
feedback from the successor activities. The only feedback is when you get to
maintenance and collect PRs/CRs from the customer and start the whole thing
again.

The practical versions introduce some feedback loops but typically only up one
level at a time. So test obviously feeds back to development which feeds back
to design, etc. The problem here is that this is still a very slow process.

The problem with waterfall (the practiced version) beyond the poor feedback
loops is also the time delays involved. Your analysis board which decides
which PRs/CRs to work on may only meet every 6 months. So the average PR will
sit in a queue for 3 months before it's even considered for work. And the
results of the analysis board may not make it to the developers for another 3
months so the average PR won't be worked on for 6 months. And because _many_
PRs are collected and started at once, integration testing typically waits
until they're all done. So it could be a year or two before a full integrated
build is produced and an issue discovered which forces you back to the design
phase to fix a critical issue.

And, while the developers and testers are doing their thing another analysis
board meeting happens and introduces more PRs. By the time a product gets
released it's often 1-3 years behind what the customer actually wants or
needs.

Waterfall only works if you have trivial projects, or projects with very
clearly defined scopes and requirements that are being planned on the order of
years or even decades anyways. This isn't most software.

------
kendowns99
Let's say waterfall == large batch size. The actual problem is the large batch
size.

The larger the batch size, the less time you spend designing, coding and
delivering, and the more time you spend (mis)managing the batch - what goes in
it, changing what goes in it, planning what goes in it, explaining what will
go in it, explaining why half of it didn't go in it.

All of this invites a certain type of personality who is not incentivized to
deliver but to talk about delivering. That is when the horror stories start.

