6 ms·

Managing the Development of Large Software Systems (1970) [pdf]

56 points by musha68k 11y ago

simula67 11y ago
For those missing context, this seems to be the first paper formally describing the "Waterfall Model" for software development.
paulajohnson 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
- nickpsecurity 11y ago
  That blew my mind, too. He preempts Spiral/Agile, re-did diagrams for complexity of real-world development, discoveries of maintenance phase as hardest, legal battles over blame, buy-in by stakeholders, mock-ups to catch requirements/design issues early, noting that's necessary in first place, and so on. Reading it makes me wonder what the (censored) people were reading when they described waterfall as a static, unrealistic process? In reality, it's so forward-thinking and accurate I might have to rewrite some of my own essays that were tainted by slanderous depictions of his Waterfall model.
gcandal 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Probably Haskellers: always praising lazy evaluations. ;)
- bklaasen 11y ago
  Brian Okken of the Python Testing podcast did a nice job explaining the importance of this paper: http://pythontesting.net/podcast/waterfall/ http://pythontesting.net/podcast/waterfall/
- dang 11y ago
  It was Craig Larman who did the original research on this: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... An old HN comment about it: https://news.ycombinator.com/item?id=990463 https://news.ycombinator.com/item?id=990463
0xdeadbeefbabe 11y ago
> 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.
nickpsecurity 11y ago
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. ;)

56 points by musha68k 11y ago

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

paulajohnson 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.
nickpsecurity 11y ago
That blew my mind, too. He preempts Spiral/Agile, re-did diagrams for complexity of real-world development, discoveries of maintenance phase as hardest, legal battles over blame, buy-in by stakeholders, mock-ups to catch requirements/design issues early, noting that's necessary in first place, and so on. Reading it makes me wonder what the (censored) people were reading when they described waterfall as a static, unrealistic process? In reality, it's so forward-thinking and accurate I might have to rewrite some of my own essays that were tainted by slanderous depictions of his Waterfall model.

gcandal 11y ago

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 11y ago
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 11y ago
  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 11y ago
    Probably Haskellers: always praising lazy evaluations. ;)
bklaasen 11y ago
Brian Okken of the Python Testing podcast did a nice job explaining the importance of this paper: http://pythontesting.net/podcast/waterfall/ http://pythontesting.net/podcast/waterfall/
dang 11y ago
It was Craig Larman who did the original research on this: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... An old HN comment about it: https://news.ycombinator.com/item?id=990463 https://news.ycombinator.com/item?id=990463

0xdeadbeefbabe 11y ago

> 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.

nickpsecurity 11y ago

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. ;)