
Managing the Development of Large Software Systems (1970) [pdf] - musha68k
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
======
paulajohnson
This paper doesn't just describe the waterfall, it explains why it doesn't
work and proposes a more iterative approach, albeit with only two iterations.

~~~
Jtsummers
If by two iterations you mean the paper suggests only going through the
various components processes at most twice, that's not accurate. The method
proposed involves feedback loops (Analysis->Design->Analysis->...) that could
repeat multiple times. And the single steps back are the ideal. That is, you
don't want to have to go back to Analysis from Testing, but you probably will
have to for some projects from time to time.

~~~
rossk14
I got the impression that the paper was suggesting an early, disposable
prototype during the preliminary program design phase, similar to what Fred
Brooks suggested back in the day.
([http://c2.com/cgi/wiki?PlanToThrowOneAway](http://c2.com/cgi/wiki?PlanToThrowOneAway))
Meaning that the PPD phase was in effect an initial iteration through the
development process. The outputs from that were used to generate the program
design documents in the primary development process.

~~~
Jtsummers
I almost made a comment about that part. But that's the _only_ part that's
restricted (and then not strictly) to two "iterations". But I don't think that
was what OP was referring to.

> This paper doesn't just describe the waterfall, it explains why it doesn't
> work and proposes a more iterative approach, albeit with only two
> iterations.

The iterative steps involved are _not_ the throw one away bit, but the
feedback loops in between the different stages of development. And the paper
does _not_ restrict its model to two iterations.

The throw one away portion are the prototyping phase, which is the same
development process in miniature. Like how, here, we might prototype our radio
software without the hardware at all just to make sure we understand the
protocol and other aspects correctly so when we do the full development on the
radio (often with reused code from the prototype, though) it's better
informed. [0]

[0] Though, true to form, the last prototype became a delivered product
instead of the basis for the final product. Oops. The dilemma of making a too
good prototype, but not engineered well enough to actually be a final product.
Maintenance has been a beast.

------
simula67
For those missing context, this seems to be the first paper formally
describing the "Waterfall Model" for software development.

------
0xdeadbeefbabe
> If documentation does not yet exist there is as yet no design, only people
> thinking and talking about the design which is of some value, but not much.

I'm having a hard time remembering how we do things better in modern times
without writing documentation.

------
gcandal
I first came into contact with this article via
[https://www.youtube.com/watch?v=NP9AIUT9nos](https://www.youtube.com/watch?v=NP9AIUT9nos),
which is a pretty decent analysis on how people misinterpreted the original
concept.

~~~
gonzo41
I first came into contact with this article through this talk
[https://www.youtube.com/watch?v=csyL9EC0S0c](https://www.youtube.com/watch?v=csyL9EC0S0c)

Its entertaining

~~~
musha68k
I first came into contact with this by way of Dave Farley's sobering "The
Rationale for Continuous Delivery":

[https://vimeo.com/147863304](https://vimeo.com/147863304)

He's essentially mocking our whole field for reading the paper lazily :) "This
paper was a description of what not to do."

~~~
nickpsecurity
Probably Haskellers: always praising lazy evaluations. ;)

------
nickpsecurity
How did I never read this paper before now!? People have been bashing
waterfall for a long time. If this paper originated it, then the resulting
waterfalls say more about the readers and IT culture than the visionary that
recommended a very, adaptive process. A few points on the paper.

The author describes the software development as a creative process. Most
managers and even many CompSci researchers thought it was mechanical with
potential for automation and assembly-line type guidance. He wisely
contradicts that in a way that I hope was to help us all out by putting
reality in management reader's heads.

I used to think one person did waterfall followed by other models (eg Spiral)
realizing initial work usually failed and is rewritten. Now I know it's the
opposite: waterfall author knew requirements or design would require rewrites.
Even made new diagrams for it. Diagrams most of us never saw while ideal model
was plastered everywhere. He underestimates how difficult coding part can be
but his claims still proved out with methods like Cleanroom and Correct-by-
Construction that kept coding structures simple. Almost all defects happened
outside of coding and coding changes were straight-forward.

The documentation chapter is pure gold. Managing scope, preventing excuses
during failures, ensuring everyone is on same page, rules to keep it
consistent even by halting development, wisely noting maintenance/rework phase
is horrible enough that docs are a necessity, and handing off system to
cheaper, ops people. Those particularly stood the test of time.

In one section, he recommends implementing _something_ to get the process
started even if one doesn't know what they're doing. That's to avoid paralysis
by analysis and give something tangible to start with. Ironically, "modern"
and anti-waterfall methods recommend exactly that.

The simulation part is tripping some people up and a weird read. People take
it too literally. What I'm seeing is a call for prototypes that explore some
of the user interface, key calculations, structure, I/O, and other trouble
spots. The stakeholders each review a bit of this to spot early requirements
and design problems. The next section mentions feedback loops that do the same
thing which collectively result in buy-in by those paying. Just shows he
wisely considered a critical human factor that led to many project failures
later on.

So, it was a short and delightful read whose advice should've led to many
successful projects and hastened arrival of more Agile methods. Instead,
people cherry-picked his points and even slandered him in subsequent work. All
kinds of disaster followed.

Least I know now that the real Waterfall was designed to prevent that and
probably would have most of the time. So, props to Dr. Royce for being one of
the giants whose shoulders we stand on trying to make IT great. Well,
should've stood on for many. ;)

~~~
mannykannot
The word 'waterfall' does not appear in this paper, not even to describe the
model that Royce is criticizing (and it would be a completely inappropriate
and misleading metaphor for the model he is advocating.) I suspect the use of
'waterfall' as a model of software development is a retronym coined (possibly
by Royce, elsewhere) for what was once the only model of systematic software
development, once its shortcomings and the need for an alternative became
apparent. It has persisted because it is a convenient straw man: it is easy to
make almost any new model look good when you compare it to the waterfall
model. We should have burned this straw man long ago: 45 years have gone by
since Royce explained its shortcomings and proposed better alternatives, so by
now, we really should be able to justify our latest methods with something
more than just "better than waterfall".

~~~
nickpsecurity
Great points. I guess the pdf being called waterfall threw me on that part.
Maybe we should call his the Royce model instead, eh?

