The Irony of Waterfall

The irony is never lost on me when I hear people discussing waterfall. I pray that no one will ever misconstrue me as much as poor Winston Royce is misconstrued today.

From the second page of the paper (what most people consider as waterfall).

Screen Shot 2012 08 01 at 11 55 14 AM

Now Royce has the following to say about this:

“I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

Sounds a lot like the arguments people make against waterfall right?

Now I may disagree with some of the assessments made by Royce (importance of documentation being one) but the irony of associating the chart above to him never misses me. Read the paper, waterfall as presented by most people is a strawman

This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

11 Responses to The Irony of Waterfall

  1. Gilliam Bates says:

    @Josh Kodroff

    Well the first clue for you is it says “Copyright 1970″ on the bottom of the first page

  2. Scott Janssens says:

    When a project that purports to be using agile methodologies fails, the response is usually “you didn’t do agile correctly”. No one ever says you didn’t do waterfall correctly. In my experience projects fail because they don’t adhere to a methodology at all.

  3. Chris Tavares says:

    The reason there’s so much emphasis on documentation is because the waterfall paper was proposed as a process to meet the requirements of MIL-STD-2167A (or it’s predecessor). The DOD requires every project it builds to have documentation that weighs as much as the team that built it (at least it seemed like it to me), and each piece of paper has a government required purpose.

    The DOD assumes engineers are interchangable cogs, and to attempt to make this so they require massive amounts of documentation. It doesn’t work out so well in real life.

  4. Way back, we did a big waterfall system that had very rigid performance requirements. During the analysis and design we built many a proof of concept to show that the underlying technologies would perform as expect. They did. It worked well.

    To me the problem with waterfall is that the time constrains of most projects are way less than the actual time needed. This forces people to short-cut significant aspects of the analysis and design. Since a waterfall project is most often over a period of years, as it progresses people eventually realize that the short-cuts come at a cost. An expensive one. This “scope creep” could have been picked up initially, but suddenly towards the end it comes back to haunt them.

    If you accept that as the ‘risk of human sloppiness’ then the more you pile on and the longer you work on it, the worse the side-effects of sloppy analysis and haphazard design will be. If you break stuff up into little iterations, sometimes those issues will raise their head early enough that the downstream effects are minimal. That is, you catch the problem early enough to make fixing it significantly less work.

    But, of course, iterations will not save you if you’ve gone off and built the wrong thing. And because they are shorter, you’re less likely to admit that you’ve built the wrong thing and just keep trying to hopelessly iterate yourself into something better. So, as one might expect, if you’ve built the wrong thing, you pretty much have to throw it away and build the right thing instead. Process can’t save you from that, but a good architecture will reduce the pain.


  5. gregyoung says:

    Have you read the dates on the paper and what kinds of systems were being discussed?

  6. Josh Kodroff says:

    With all due respect to Dr. Royce, the language he uses seems to indicate that he hasn’t spent much time actually coding on real projects:

    “A simple octal patch or redo of some isolated code will not fix these kinds of difficulties.”
    For realz? Anyone submitted an octal patch recently?

    “The first rule of managing software development is ruthless enforcement of documentation requirements.”
    Come on, son. That is so far out of touch with what’s actually important in software projects I can’t even process it.

  7. Johnno Nolan says:

    What I find ironic is that people who berate ‘waterfall’ are just using that particular methodology to describe ‘not agile’. I’ve worked in many organisations and none of them have done waterfall. It’s mainly been chaos. When orgs do suddenly start to become ‘agile’ they typically take on the restrictive disciplines. So what orgs are actually doing when they become ‘agile’ is becoming ‘waterfall'(y).

  8. gregyoung says:

  9. Neil says:

    I always thought it was named because once you’re underway, change and flexibility are like kayaking up a waterfall.

  10. Miguel Alho says:

    Could you review your link to the paper? It seems that it doesn’t exist.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>