
The Waterfall methodology was a historic accident and they knew it - janvdberg
http://beza1e1.tuxen.de/waterfall.html
======
jl6
I work for a corporation that has worshipped Waterfall for many decades. We
are now in the middle of a years-long large scale “switch” to Agile, which is
a vast cultural change.

My observation is that Agile is all about software development, tuned for
software development, and for the benefit of software developers and the
customers of software.

Obvious, right?

What’s not so obvious is that a surprisingly small portion of what people
think of as a software project is actually about software development.

Interacting with 3rd parties, writing contracts, hiring developers, planning
how your project interacts with other projects and the wider organization,
responding to regulations and external enquiries, managing the demand for
certainty from stakeholders, obtaining funding, maintaining financial
control...

These are the issues that real software projects have to deal with, and Agile
is silent (if not actively hostile) on how you should deal with them.

If your project is truly _just_ about developing software, sure, be Agile
about it. But it’s not through ignorance that people “fall” back to Waterfall
in the face of real world constraints.

~~~
jdlshore
> Interacting with 3rd parties, writing contracts, hiring developers, planning
> how your project interacts with other projects and the wider organization,
> responding to regulations and external enquiries, managing the demand for
> certainty from stakeholders, obtaining funding, maintaining financial
> control...

These aren't part of Agile 101, but the Agile community has been discussing
these things for _years_. I first heard Mary Poppendieck discuss Agile
contracts in 2006 or so [1]. Pat Reed has been talking about Agile accounting
since at least 2014, and I doubt that was the beginning of it [2]. My book
discusses techniques for making commitments to stakeholders, and it was
written in 2007 [3].

Literally Google the phrase "Agile" \+ anything you wrote and you'll find a
wealth of resources. If you're not finding that information, it's because
you're not looking.

[1]
[http://agileconsortium.pbworks.com/f/AgileContracts.pdf](http://agileconsortium.pbworks.com/f/AgileContracts.pdf)

[2] [https://www.slideshare.net/ITRevolution/wednesday-530-pat-
re...](https://www.slideshare.net/ITRevolution/wednesday-530-pat-reed-gb-
final)

[3] [https://www.jamesshore.com/Agile-
Book/risk_management.html](https://www.jamesshore.com/Agile-
Book/risk_management.html)

~~~
blub
The agile community is currently an amorphous blob of people connected by
words like "Agile!", "Scrum", "TDD" and so on. Agile was stolen from its
creators and mutated into a corporate version - which I have to say I find
pretty darn funny.

Point is, that info is certainly not included in any of the Agile resources
I've seen. The only one that handles some of this is Ambler's D.A.D, but I
didn't bother reading that for a simple reason: after seeing various Agile
methods (mostly Scrum) fail so much, I've come to the conclusion that Agile
development processes do not represent a real-world solution.

There's always an excuse why Scrum fails in practice, but in the end it
requires such a paradigm shift from our typical development approaches in
order to succeed, that it's about as useful as a diet plan that only works on
super-athletes.

XP is in zombie mode for a decade, Scrum is only good for mobile apps and
small websites, Kanban is not even a way of making software. What are we left
with? Scaled Agile, LeSS, which even the original Agile people bitterly
complain about? These won't work either, but I know some consultants make a
crapton of money selling them to corps.

~~~
shandor
> I've come to the conclusion that Agile development processes do not
> represent a real-world solution.

I think one of the problems regarding this whole discussion, whenever it stirs
up, is that Agile (as defined in the original manifesto) is explicitly _not_
about any particular processes, but still most of the critique against Agile
seems to actually be against different kinds of "agile processes". The
manifesto explicitly states "Individuals and interactions over processes and
tools".

In real world, one of course needs actual processes, and all kinds of consults
are trying to ride the wave to lucrative contracts. But since the Agile
Manifesto is about _values_ , not processes, you cannot steal it from its
creators. You can pervert the meaning and utilize some braindead processes in
your company and call them "agile", but that doesn't lessen the worth of the
original values.

I know that that's a highly unsatisfactory answer, a kind of a cop-out, but I
think applying more to Agile than it's meant to be is part of the problems
surrounding it today.

Edit: those "you"s are meant for passive voice. No personal offense or
commentary meant.

~~~
blub
The road from Agile values to having something that can be used to ship
quality software is way too long. "Eat well and do sports" is correct, yet
ineffectual advice, since many countries still have a big problem with
obesity, diabetes and other modern diseases.

There are two things undermining "the values" in practice:

1) The economic and social environment doesn't encourage an
engineering/scientific approach to SW development. Nor does it encourage
eating well or having an active lifestyle.

2) People need a lot of help to implement those fuzzy, high-level values and
will always reach for some process / diet / plan.

All things considered, it's probably better to be agile, but how do you
actually deliver a quality, successful SW project? Let's talk about that
instead of fuzzy old Agile.

~~~
shandor
I agree with your conclusion fully. Also your link to "eat well and do sports"
is kind of exactly what I was after. I mean no one is saying that eating well
is _bad_ for your health, right? What I was trying to convey is that I think
similarly of the Agile Manifesto itself.

Because we shouldn't infer that eating well is bad because a lot of people try
to eat well and are still obese, we shouldn't infer that Agile as in the
Manifesto is bad because lots of companies get burned by Scrum. We should be
coming to conclusions like "hey, maybe this Scrum thing we tried is shit,
let's try some other process that seems to align with these fuzzy agile values
we believe in".

The problem I have with the current discourse around the matter is that as
long as we keep bashing "The Agile Values" when we mean "agile processes as
implemented in framework ZZZ", we are not having the discussion of "hey, which
process would align better with these values while letting us ship quality
software rapidly".

------
fergie
Its problematic that Waterfall/Agile stuff regularly gets upvoted to the front
page, and then the majority of commenters don't seem to read the article
before posting some tangentially related anecdotes on the vague topic of
"Agile".

This article is making the point that a "Waterfall Method" has never actually
been proposed by academia, so it is incorrect to speak about an
Agile/Waterfall dichotomy. In other words: The Waterfall Methodology is not a
thing and only seems to be used as a "straw man" foil.

Personally I think we should also be a little more critical about who defines
"Agile", how it differs from common sense, and what research has actually been
done on it, but thats another matter.

~~~
sonnyblarney
"The Waterfall Methodology is not a thing and only seems to be used as a
"straw man" foil."

Waterfall is a 'thing' because it existed long before software or computers.

I view it as essentially the most obvious form of project management, which is
simply a phased approach to solving a problem: gather requirements, plan,
design, do, test, fix problems etc..

~~~
acdha
I think that’s the core problem, too: it works fine for well-defined needs in
mature categories — things like buying printers or renting office space, where
all of the options are usually capable of doing the job to at least a basic
level. Large organizations have tons of experience muddling through that
process and it’s tempting to think that software is similar, especially
because many vendors are will to perjure themselves saying so.

The problem was accepting that custom software doesn’t work in the same way
and reconciling the huge differences in how much customization people request
versus what they are willing to pay.

------
timoth3y
I think waterfall was adopted for software development, not by accident, but
because it was a well-defined methodology with proven effectiveness in areas
like construction and manufacturing.

In areas where changes to the spec are expensive, like building a bridge,
waterfall methodology makes a lot of sense. Now that dev tools are so good and
computers so powerful, spec changes are cheap, so waterfall is inappropriate.
However, there may be times where it is appropriate; maybe a controller for a
pacemaker or an oil refinery.

I see it as using the right process for the right job.

~~~
wpietri
I don't think this bit is correct:

> it was a well-defined methodology with proven effectiveness in areas like
> construction and manufacturing.

If you look at major construction projects, waterfall approaches don't have a
great track record. E.g., the San Francisco Bay Bridge had enormous cost
overruns: [https://www.citylab.com/equity/2015/10/from-250-million-
to-6...](https://www.citylab.com/equity/2015/10/from-250-million-
to-65-billion-the-bay-bridge-cost-overrun/410254/)

In contrast, the Empire State Building was not built with a waterfall
approach. It was delivered on time and 18% under budget. I saw Mary
Poppendieck, who has written some excellent books on software development,
give a fantastic talk on it. There's a write-up of a related talk of hers
here: [https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-
of...](https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of-the-plan/)

My belief is that the waterfall approach is common not because it's effective,
but because it conforms to certain naive fantasies people -- especially
powerful people -- have about projects. I think it's basically King Canute
writ large. (Large, and into a zillion GANTT charts.)

I do agree that it's inappropriate for modern software projects. But I think
this is also suspect:

> maybe a controller for a pacemaker

I've talked with a number of medical-device people, including Nancy van
Schooenderwoert, who has been involved in the Agile world for at least a
decade:

[https://sdmdglobal.iqpc.co.uk/speakers/nancy-van-
schooenderw...](https://sdmdglobal.iqpc.co.uk/speakers/nancy-van-
schooenderwoert)

They believe that Agile approaches are way better even for life-critical
systems. You do need much more rigorous testing, but given the way Agile
approaches deliver core functionality early, you end up having way more time
for that testing, and many more opportunities to discover ways to improve the
testing approach.

~~~
tomnipotent
You should spend 30 minutes talking with a project coordinator for any
construction job and you'll change your mind.

My company recently opened its first retail store in a new Caruso mall, and it
was a considerably eye-opening experience. The pace (and cost) is frustrating,
but the end result is generally fantastic and that's more than I can say for
most software projects.

Even for a simple job, the number of things that need to align to allow for a
dump truck to deliver gravel to a construction site is non-trivial. Along with
permits and what times the truck can arrive depending on whatever bureaucratic
bullshit is at play, you also need to make sure the rest of the crew is in
place to receive the delivery and put it to use. Don't forget about the things
that need to be done even before the gravel can be delivered, and things
dependent on the delivery that begin on that task is complete.

This isn't a software project. A simple truck delivery being late can require
dozens of people to get involved to reschedule everything else that needed to
come after it - this is non-trivial, expensive, and can impact hundreds of
people depending on how much the schedule slips since we often dealing with
hourly labor.

"But it's only changing one delivery" you say? The delivery was probably
handled by a contractor, which has other clients and other responsibilities
and may not be able to reschedule when it's convenient for you. Multiply this
by every contractor or 3rd party you're working with and suddenly Metcalfe's
law is punching you in the face.

The waterfall approach exists because it works - on average - considerably
better than everything else that's been tried before it, regardless of
whatever cosmic forces we think are at play.

~~~
groestl
I did spend a lot more than 30 minutes with a project coordinator, and complex
construction projects seem to align remarkably well with software projects.
Spikes, iterative approaches, severe changes in project goals/architecture
while construction is already in progress, budget cuts just before the
projects is almost done... it's all there. "We paid an unbelievable amount for
a Gantt chart, and it was already outdated when it was delivered" he said.

~~~
Nimitz14
> I did spend a lot more than 30 minutes with a project coordinator, and
> complex construction projects seem to align remarkably well with software
> projects.

I don't understand how you can say this with a straight face. Material costs
for software projects are nonexistent (and don't come at me with AWS blabla,
it's still way less than when building physical things). Hitting delete on
what you've done so far costs nothing. Construction is pretty straightforward
in that even if there might be different approaches to building a certain
object (like a wall), these different approaches are agreed upon (as in people
agree each is a valid approach and will choose which based on the pros/cons of
each). Unlike in software where there exists no agreement in how to approach a
problem and each programmer out there will probably provide a different
solution.

~~~
heavenlyblue
I think you're quite a bit delusional here. Construction industry and the
software industry are asymmetrically different from each other in the
complexities you'd need to deal with.

For example, there might be many ways to do the same thing in the software
industry, but you might have already dedicated yourself to proving that a
given solution works "good enough". So hitting "delete" on that solution would
require unmaintainable at that step amount of coordination between many teams
who are using your code.

Construction doesn't deal with constant changes to the laws of physics, but
software industry has a churn rate of APIs of about 1 new version every 6
months, all of which need to be constantly overseen and accounted for.

Did construction industry have anything like GDPR happen to it in the last 20
years?

~~~
tomnipotent
> Did construction industry have anything like GDPR happen to it in the last
> 20 years?

You mean like regulations and building codes so that we don't have incidents
where apartment buildings collapse like in China?

Some tests to get certain architecture certification require them to literally
memorize different rules from everything to how close an AC unit can be to
certain things. There are a LOT of rules to follow.

------
bpyne
It's amazing how many times over my career I've watched and participated in
debates on software development methodologies. HN seems to have one at least
annually.

The author of the post does a good job summing up the issues. I only skimmed
it but have to agree with everything I read.

I can add that there's a time and place for Waterfall: when requirements are
well-known and static and when lots of oversight is needed. I can also add
that no methodology has successfully dealt with the mega-projects we read
about in software engineering case studies.

Building stuff, whether it's software or anything other product, is hard. It's
messy. Often the requirements are not well thought out. In the situations I
normally deal with, a requester can state a high-level strategic goal for the
organization, but not how the software can get us to it. That's where my team
gets involved. One engineer I respect highly once said that we need to get
something in front of the requester quickly so that we can find out what (s)he
doesn't want. By process of elimination, the idea foments in the requester's
mind and requirements become more concrete.

Again, though, some organizations are very static or they deal with software
whose failure can be catastrophic. In those situations, the highly
bureaucratic Waterfall method can be helpful at least for slowing down the
process.

~~~
pmart123
I think the "Mythical Man-Month" does a great job accounting for the process
and implementation of a mega-project. But as Brooks even stated, there's "No
Silver Bullet."

------
seanc
I don't know about an accident, necessarily. It's got two important things
going for it.

1\. It lets everyone involved cover their ass. "All I'm responsible for is my
function. There was a problem with my inputs, so no wonder my outputs suck.
Don't blame me, my inputs are all right there in black and white, and you
signed off on them."

2\. It gives people the comforting feeling that they can predict the future,
and then do things like plan budgets or negotiate fixed price sales contracts.
Predicting the future is irresistible for people who handle money. As
fictional as it might be.

So those two things, I think they have a momentum of their own, and without
constant vigilance and effort, for most domains, waterfall development is a
sad, inevitable default.

~~~
dreamcompiler
Completely agree. The recent discussion here about Jira confirms this: Any new
software development methodology -- however well-intentioned -- eventually
will be distorted into the waterfall model with a sexier name. The incentives
for doing so are much more powerful than the incentives for sticking with a
truly better development process. If we want to change this, we have to change
those incentives.

~~~
mlthoughts2018
I agree with you, except I’d say that the ideal of Agile, the manifesto
itself, responding to change, etc., is a significantly _worse_ workflow
process than Waterfall (which is also bad).

Agile prescribes so many things that are absolutely pushover, toothless
concepts in the face of basic corporate bureaucracy that it really is a case
where it’s the tool’s own fault that everyone uses it wrong.

I’ve seen Waterfall used successfully. Not often, but on a few defense
research projects it was great.

I have never once seen or heard of any Agile process anywhere actually working
with any degree of success.

I’ve heard plenty of people indulging some No True Scotsman nonsense about how
a “real” Agile process can succeed, and then proceeding to write a diatribe
about their “real Agile” workplace that is clearly so fucked with dysfunction
that the person writing can’t even realize they are only shipping software _in
spite of Agile_ and not the least bit _because of it_. But I’ve never ever
seen or heard of it actually _causing_ success, not across any of the
countless blog posts or anecdata on HN, and not across 6 different jobs at
companies of various ages, sizes and capitalization levels all using Agile
withvarying degrees of formality, pragmatism, Agile coaching and consulting,
etc.

None of it made any difference. Agile just hinders people. It is not capable
of doing otherwise.

Now, having said all that, I do agree that for processes that can work,
processes that are not overly prescriptive, let different teams do things
different ways at different times based on different goals or different
personnel, let teams ignore the customer when needed, enforce long-term
planning when needed, do pure research with no time boxing when needed, etc.,
then _for those kinds of common sense, non-Agile processes_ , we have to
change the incentives so that people are aligned to care about the objective
truth and objective outcomes required to get the job done.

~~~
com2kid
> I have never once seen or heard of any Agile process anywhere actually
> working with any degree of success.

I ran a team were we shipped (firmware!) every 3 weeks.

After the first year of tracking all our numbers we were able to hit our
estimates within a few hours +/\- for the entire team.

3 week sprints, 2 weeks writing code, 1 week testing and bug fixing.

It wasn't perfect, and learning how to do it was painful, but once we got
going it worked great.

We didn't adhere strongly to any one guiding principle, but being able to use
sprints to align work across multiple teams, and as a planning mechanism for
management was incredibly useful.

"Our breakdown of that feature means it'll take 3 sprints in total, the last
of those sprints the work is split across 2 devs, if one of those devs gets
reassigned it'll take 4 sprints."

Being forced to actually plan work out, and then being held accountable for
the hours, meant that over time we got good at estimating, and knowing how far
to break work down. There is of course a trade off between gains from breaking
work down, and time spent doing the breakdown! Several months were rather
painful when we went too far one way, and then inevitably the next few months
swung too far in the other direction.

But in the end? Yeah it all worked out. We figured out what length of sprint
worked for us, what type of estimation system to use, and how much work to put
into our planning sessions.

FWIW one of the huge benefit of doing the work breakdowns is being able to see
opportunities to parallelize work, and also to see natural stopping points.

My team was lucky to have someone almost full-time dedicated to managing our
workflow, without that the entire process wouldn't have been tenable. The
tools just suck up too much time.

~~~
mlthoughts2018
> “Being forced to actually plan work out, and then being held accountable for
> the hours, meant that over time we got good at estimating”

I’m skeptical of this, because even working in a team that had many person-
decades of experience of estimating software delivery, the consensus opinion
was that nobody’s estimates are worth anything and that the business would
actually be worse off using estimates even as mere guidelines than just
working on things, hitting blockers, and adjust expectations as you go.

But regardless it sounds like your process was fairly different from Agile.
The only superficial similarity was having some notion of a regular sprint
cadence, but cadence based scheduling is common to many project management
strategies. It sounds like you had something very pragmatic for your exact
situation, which is great — that’s the whole goal, the very thing Agile
paradoxically does not conceptually support.

~~~
AnimalMuppet
I've worked on an agile team (specifically XP). The idea there was that
estimates diverge from reality past 3 weeks. If the estimate is bigger than 3
weeks, break it down into smaller pieces and estimate those.

Also, XP was very into feedback. "How much did we get done in the last two
weeks? How much did we think we were going to get done? Let's use that to
adjust our estimates going forward." This was actually done with story points,
so that when we "adjusted", the units of estimation stayed the same (that is,
an item that was 4 story points before was still 4 story points), but we
realized that the team was only doing 12 story points per 2-week sprint,
instead of the 20 that we expected.

And yes, it worked very well for us, and it was truly agile.

And I disagree with you that agile doesn't allow something tuned for your
exact situation. Or rather, agile allows that, even if Agile doesn't. We'd
sometimes say "For the next two sprints, we're going to tweak our approach in
this specific way. If it works, we'll keep doing it that way." That is, our
process was one of the parameters we could adjust.

~~~
speedplane
> I've worked on an agile team .... The idea there was that estimates diverge
> from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it
> down into smaller pieces and estimate those.

That's not really all that agile. The agile teams I've worked on try to break
things down much smaller, ideally half-days or less. Any estimate of how
complex some task is, is often off by a factor of 2, sometimes much more. Only
by breaking down tasks into small bits can you really start getting a handle
on your velocity and complexity of a project.

~~~
AstralStorm
Not true at all. Every increment is supposed to be shippable and better
quality than the one before. So the chunks cannot be too small or you risk
never shipping by never shipping critical functionality that is hard to chunk,
or instead you end up with long stretches where software does not work and is
not testable.

This also ignores the fact that there are evolutionary dead ends and digging
yourself out of such a hole is hard.

~~~
speedplane
> you risk never shipping by never shipping critical functionality that is
> hard to chunk

You don't have to be perfect at dividing up a big project, but you should at
least try. Breaking down big pieces of functionality into smaller pieces is
one of the core tenants of Agile.

In fact, your approach has far more risk. By refusing to try to break things
down into smaller units, you risk not shipping anything because every feature
is deemed "critical".

------
Spooky23
It’s no accident. Waterfall is driven by government procurement regulations.
If the components of the waterfall look uncannily like a high level work
breakdown structure of a project... that’s because it is.

The historical philosophy of government procurement is not just an outcome,
but a competitive process. In many circumstances each part of delivery let to
bid, and bidders performing design work cannot implement.

Even today, design-build (aka agile) is fairly limited in most procurement
scenarios.

The thing that’s hard for people to grasp is that equity in procurement often
yields increased cost and timelines. If vendors don’t price risk into bids,
they lose money and fail to deliver. The government compensates with more
stringent requirements that make it harder to bid, which shrinks the bidding
pool, etc.

~~~
cheschire
Indeed. The documents referenced in the OP seem like the eventual attempt at
squeezing software development into the confines of Public Law 93-400[0],
which predated the DOD Standard doc from OP by a good decade, and the Federal
Acquisition Regulation which was an evolution of the Armed Services
Procurement Regulation originally published in 1947!

In my opinion, these concepts are fundamental to the successful functioning of
a monopsony like the government, who is also subject to it's own equitable
competition laws.

0:
[https://www.gpo.gov/fdsys/pkg/STATUTE-88/pdf/STATUTE-88-Pg79...](https://www.gpo.gov/fdsys/pkg/STATUTE-88/pdf/STATUTE-88-Pg796.pdf)

------
paulryanrogers
Interesting, I always thought that spec-first and rigorous testing
methodologies came from limitations in technology. For example without the
capacity for constant updates software had to be as close to perfect and bug
free as practical before distribution. I cannot imagine doing agile on a
widely distributed software project as it is done today with games and their
day-one patches.

EDIT: rephrasing for clarity

~~~
whatshisface
> _without the capacity for constant updates software had to be as close to
> perfect and bug free as practical before distribution_

In some cases, there is a downside to incorrect behavior that is worse than
"oops we'll have to patch it." This category includes anything that handles
money, industrial equipment, scientific data, or anything that isn't a
computer game or adtech.

~~~
prevedmedved
Adtech handles money. It's financial software that also needs to be (soft)
real-time. It's harder than the usual money software.

~~~
AstralStorm
Adtech loses income, not money. There is a vast difference.

Additionally you can have rollbacks - strategy applied by many banks when
things break.

Funny enough, safe reverts and rollbacks require specialized up front design,
it does not happen on its own. Safe automatic updates with no state loss?
Same.

~~~
lmm
> Adtech loses income, not money. There is a vast difference.

Placing bids is (potentially) spending money. A bug in your adtech platform
can absolutely bankrupt you in the very direct way of spending more money than
you have.

------
hondish
From the script of The Mother of all Demos (its 50th anniversary noted
elsewhere in HN)[1]:

"...the general approach for us, empirical but pursuing this monstrous goal,
monstrously difficult to like building and trying empirically, and we’re
approaching it evolutionary-wise because we feel that it’s a whole system
problem, you need to get a person in that environment, working and looking at
the many aspects of his working system that are involved in his effectiveness.
That’s many more things than just these computerated tools. And in a large
system like that, we need to do it evolutionary-wise because we can’t be
analytic enough about it at any one point, to decide what best our next thing
should be. We can only decide from here as well as we can analyze it, where we
can invest our next resources to get the most return that will increase of the
effectiveness of the system we have and this item down here is the term boot-
strapping applied in a slightly loose sense. We’re applying that to our
approach".

[1]:
[http://dougengelbart.org/pubs/video/fjcc68/Englebart's-1968-...](http://dougengelbart.org/pubs/video/fjcc68/Englebart's-1968-Transcription.html)

------
sgt101
A good thing about waterfall is the documentation it generates. We switched to
Agile 10 years ago, didn't manage the outsourcing all that well and now we are
in the same position as then but without the documentation. More and more I
wonder how we can get teams to write about what they are doing and teach the
next team how everything works... sadly people suspect that such efforts will
be used to outsource and offshore, but without them it's impossible to pick
apart what's happened and rationally work out where to go next.

~~~
Murk
I've seen this a number of times. People (management and team alike) have said
to me things along the lines of: "We don't have documentation, we are agile."
Which, of course is not what the agile manifesto says, but is how some people
have taken it.

Other sayings are "The spec is in the tickets, there is no user manual." "We
have unit tests." and so on.

All this makes trouble - Especially when you consider in order to change a
thing, you should aim to understand it's salient parts in the first place -
but perhaps that is not agile or the scrum way according to some.

------
gaius
There is no such thing as “the waterfall methodology”. It was a strawman set
up by the Agile camp to help peddle their wares. Everyone who was around back
in the day knows this. If you want to know what methodology was actually being
used pre-Agile check out
[https://en.wikipedia.org/wiki/Dynamic_systems_development_me...](https://en.wikipedia.org/wiki/Dynamic_systems_development_method)
, you might be surprised at how familiar it looks...

------
maxxxxx
I really wish we went away from saying things like "OOP is bad, Agile is bad,
Waterfall is bad" to realizing that pretty much any methodology can work well
or not so well depending on the type of work, the people involved and lot of
other factors. The same people who mess up waterfall will also mess up Agile
and the people can't do OOP in a reasonable way will not do any better with
FP.

In the end it comes down to constantly adapting to problems after openly
admitting these problems.

~~~
jrochkind1
In my experience even if you're not "the same people who mess up" everything,
doing it right is actually kinda _hard_, and advice on how to figure out how
to do it right is useful. Which is what these methodologies are, different
peoples/communities advice.

------
gitgud
Waterfall is far from perfect, but it has its place in many industries, where
well customers have _precisely-defined_ specifications.

In software, people usually don't know exactly what they want, let alone be
able to precisely define it. This situation lends itself perfectly for rapid-
prototyping to discover what works fast... which is basically an _agile_
approach.

------
ternaryoperator
A factor overlooked in the comments below (and in the article) is that prior
to roughly 2000, projects tended to be slow-moving and could be defined by
specifications, requirements, and design docs before any serious coding was
undertaken. So the stair-step approach referred to as waterfall was not
unreasonable.

In my experience, though, what was unreasonable was the sequence "build, then
debug." This meant spending huge amounts of time in debugging after the code
was written and made it impossible to keep projects to a schedule because the
debug/fix/rerun cycle was open-ended.

This, in my view, is where Agile has rightfully distinguished itself--by
having tests developed in parallel with code, thereby making debugging an
"every once in a while" activity rather than a whole endless-seeming cycle.

------
bbunix
The original paper is good. [http://www-
scf.usc.edu/~csci201/lectures/Lecture11/royce1970...](http://www-
scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf)

------
AstralStorm
Sufficiently accurate program and requirement specification is directly the
program itself and requires major programming skills.

Which is not possible when the person giving them is not a programmer...

The fallacy of all CASE tools stems from this.

------
bitL
So we ended up with "Waterfall" being a historic accident, "Agile" turning
into a cult, and with everybody knowing that great teams self-organize to top
it all.

------
gumby
Apart from the name, are we really sure Isambard Kingdom Brunel didn't build
his bridges the same way? Perhaps the roman aqueduct builders did too?

------
moron4hire
I've done a number of projects in both "waterfall"[0] and Agile.

On the "waterfall" projects, we wrote lots of documentation. LOTS. Business
cases for every major feature. Requirements documents with serial numbered
acceptance criteria. Design documents explaining exactly how we were going to
implement the requirements, with every REQ bullet needing to be accounted for
explicitly. Test plans showing how each DES bullet was implemented correctly
and how it proved the REQ was satisfied. And it all had to be _correct and
fresh_. We weren't allowed to have anything disagree or slip in or drop out.
If it wasn't in the REQs, it didn't go into the software.

That meant if we discovered constraints that necessitated a change in design,
we had to change the requirements. If you had to change requirements, it meant
you had to reevaluate the business case.

And that meant we were prototyping while we were writing the documentation.
The documentation wasn't done until the software was about 80% complete. By
that time, we were mostly just working the test plans and resolving defect
tickets to get to 100%.

Some of the best, longest lasting software I've ever written.

All of the "Agile" projects I've been on are what I call BTSOOP development:
"By The Seat Of Our Pants". There was no attention paid to documentation _at
all_. It was hell getting PMs to write _any_ tickets, let alone ones that were
in scope. And of the tickets that were there, most of the devs ignored them,
even if the PM didn't. Some people would mark tickets done that they just
didn't want to do, hoping the PM would just blanket-accept tickets at the end
of the Sprint. Which he most frequently did.

The difference wasn't actually process. It was accountability for failing to
adhere to the designated process. The Agile shops all had corporate policy on
how projects would be ran, and nobody was ever taken to task for it. The
"waterfall" shops didn't lack continuous integration and improvement or
responsiveness to change, we just wouldn't sign off on a particular document
until we knew it represented the final product, with linear dependencies on
when different levels of assets could be approved (not when they could be
worked on).

[0] our product manager called it "the NASA way", and we fairly closely
followed their documentation standards, if not their engineering ones, but we
were all pretty junior at the time. IDK why I was made senior other than being
the best programmer there, which at the time wasn't saying much.

------
GrumpyNl
As soon as a work method becomes a religion, its doomed to fail. Treat
Waterfall, Agile as a tool and modify it to your needs.

------
time-domain0
If you're designing something that needs to be high-quality, safe, well-
documented and is difficult to change later on, say an elevator, waterfall is
a good model to consider. For a webapp startup, hell no.

------
mannykannot
It seems that hardly a week goes by without me seeing another 'agile is better
than waterfall' post. We are so busy flogging this dead (and possibly
mythical) straw man that we are not examining the real problems of current
practices.

~~~
gthtjtkt
That's not what this article is about, not even a little bit.

------
thatoneuser
Wow speak about a masterpiece to nothing. This was a wonderfully pontificated
article about nothing.

------
berkmayer
Not a watetfall expert, but don't they teach waterfall in many universities?
How could they not see it was based on a bad example?

------
nopeacehere
Good grief.. this comments section is a disaster. Agile is far from perfect
but for software development it is FAR superior to waterfall. If you think
differently then you either have zero experience delivering software over the
last 10 years or you work for an organization that it is clearly in denial.

~~~
himynameisdom
I have to agree with this. What people need to understand is Scrum clearly
states the framework itself is not intended to solve your problems. Rather,
it's set up to unveil your problems so you and your team can solve them
yourselves.

So, if you have a ton of issues while using Scrum, that's actually kind of the
point. The real issue is not the framework that unveils your issues, but
rather the level at which a team is empowered to fix their own issues.

Scrum is both powerful and useless depending on how empowered teams are to
manage their own work. It's really that simple.

