In my experience, it seems as though the Waterfall model has proven to be too inflexible and non-responsive to requirements changes to be considered a viable method in the modern world of software development. The growth and proven track record of more agile, iterative methods seems to indicate that there is no reason why anyone should be following a process of rigid blocks that assumes little to no changes from project inception to product delivery.

Is is the waterfall development methodology still viable for delivering software systems, with respect to time, cost, and quality?

  • 3
    So, if you haven't experienced it, and don't want to experience it, that makes it dead? Not that I'm advocating for it, but that seems an odd premise. Mar 9, 2012 at 20:38
  • 9
    It's not dead. It's just not the current fad/trend/"acceptable"
    – Paul
    Mar 9, 2012 at 20:45
  • 2
    @GrandmasterB By "dead" I meant "sufficiently proven to be not the best way"
    – CFL_Jeff
    Mar 9, 2012 at 20:47
  • 3
    @Rachel Please do not continue to readd the software-development tag. It is a meta tag that is slated for future clean up.
    – Thomas Owens
    Mar 9, 2012 at 20:54
  • 3
    It's not dead, it's just resting. Pining for fjords. ;) Mar 9, 2012 at 21:27

6 Answers 6


The waterfall model that you are referring to was never intended to be a process model used on a real project. Instead, it is a strawman. It identifies the key phases and activities that exist in software projects and the most basic flow between them. This oversimplification of how to develop software is a flawed one, and it was even presented that way.

From the Wikipedia article:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.

The paper discussed is titled Managing the Developement of Large Software Systems. In it, Royce does present that model on the second page. However, the text immediately below the pictoral representation goes on to read:

I believe in this concept, but the implementation described above is risky and invites failure.

He follows this with a discussion of the problems with testing following the "completion" of the development phase, and how failures here can lead to major redesigns and code changes, and how these can lead to major overruns in cost and schedule. Throughout the paper, he refines the original model to one that is indeed viable on a project. In the end, he ends up with a model that introduces prototyping, customer interaction, and refinement of artifacts - ideas that would eventually end up being critical to the agile movement that began in the late 1990s and early 2000s.

To answer your question: The Waterfall that you are asking about is not, and never was, a viable method to deliver software projects with a reasonable amount of quality on time and budget. However, there are other plan-driven methodologies that lie opposite of agile that can and do work on projects.

  • 1
    Many articles about agile use "traditional methods" to mention waterfall, and that implied waterfall was used in the 20th century all the time. Now I know I'm wrong.
    – Ming-Tang
    Apr 2, 2015 at 7:02
  • @ThomasOwens Would you mind citing a couple of these other plan-driven methodologies that lie opposite of agile that can and do work on project?
    – Laiv
    Mar 3, 2018 at 17:50
  • @Laiv The Spiral model tends to be more plan driven than the agile approaches - you do more planning and analysis before developing working software. Cap Gemini SDM is another example, although later revisions did add in a plan-do-check-act cycle, but again it has a decent amount of up-front planning and analysis built into the process. Many are likely to be some variation of a waterfall, but with some kind of feedback loop built in. If you have a strong domain understanding and relatively stable requirements, you may not need the tight feedback loops of the agile methods and can plan better.
    – Thomas Owens
    Mar 3, 2018 at 20:16

People don't use the text-book waterfall model and probably never have.

It is an idealized, theoretical construct whose purpose is to get you to think about the steps in systems development. It's main point is that you want the bigger changes to happen as early as possible, because you'll never have the time or money to make a big change once there's a lot of code built.

Despite the fact that it is more of a way of thinking than a process, it is still very much the way that many - probably most organizations go about building software (or houses, or submarines, or whatever else...).

In the real world, you don't have totally strict cut-offs between phases, and you sometimes loop back to prior phases for small sub-projects. What the methodology tells you is not that "these things are not allowed". What it tells you is "these things cost you money and/or time" - so try to avoid that in the future.

It's all well and good for Agile Snobs(TM) to look down their noses at "old fashioned" developers and their quaint, unworkable waterfall methodology, but the fact of the matter is that Agile is no panacea either. Some projects can't be built using Agile and a lot of teams that think they're Agile are actually just sloppy and unorganized.

The methodology is not the point. The point is to think about what you're doing and why you're doing it that way - and to get the most value to the customer in the shortest reasonable time.

  • You have obviously had a very different experience of "people" to me. Over the last 30 years, I have worked in a succession of companies that all used (and still use) the text-book waterfall method. Unsurprisingly, it doesn't work.
    – David Arno
    Sep 15, 2017 at 13:07
  • @DavidArno The closest I've ever seen "in the wild" to textbook Waterfall in a software context was in a company building software that controlled train switching. The motivation there was not having someone literally die as a result of a bug. I imagine it could also happen in places doing embedded programming where you don't want to build a million of something just to find out it fails due to a bug. I tend to think that even in these cases, Waterfall is more of an ideal than a practice which is achieved with perfection. As you point out - the results are inevitably failure at some level.
    – Joel Brown
    Sep 15, 2017 at 19:45

The mythical waterfall process that is most often compared against agile never existed and therefore can not be considered dead. Real waterfall processes are still alive and well, and excelling at delivering on time on budget software that meets user expectations.

  • 5
    Not sure what the difference is between the "mythical" waterfall process and the "real" one. Will you please explain this?
    – CFL_Jeff
    Mar 9, 2012 at 20:43
  • 6
    Often the Waterfall process described by Agile proponents is a strawman en.wikipedia.org/wiki/Straw_man
    – jfrankcarr
    Mar 9, 2012 at 20:49
  • 11
    This would be a better answer if you explained in your answer how Agile proponents create a straw-man process that won't work, but is not properly Waterfall. Mar 9, 2012 at 23:04
  • 4
    -1 for the statement, "They are excelling at delivering..." The truth is that it is a wash. Like all software methodologies, sometimes it works, sometimes it doesn't. I've seen both in the case of the true waterfall method.
    – riwalk
    Mar 10, 2012 at 14:48
  • 2
    I'm going to have to say, [citation needed] on this answer. And -1 until it's provided. Especially the "excelling at delivering on time on budget software that meets user expectations" The CHAOS report disagrees with you.
    – Malfist
    Mar 11, 2012 at 10:11

Perhaps a better way of asking what you're getting at is, "when is less iterative and more formal better?"

There are situations where this is the case:

  • When the requirements won't change.

  • When meeting new requirements is less important than hitting 100% of the original ones.

  • When all the technology components are mature and well understood.

In a sense you can take the opposite of what might drive you to be agile.

Very few techniques are applicable everywhere. Very few have no use.

  • 1
    What in the world is "lessnitwrative" or "morenformal"?
    – Aaronaught
    Mar 10, 2012 at 19:42
  • 1
    @Aaronaught - "less iterative" and "more formal" typed by fat thumbs on an iPhone. :-)
    – MathAttack
    Mar 10, 2012 at 20:26
  • 1
    I haven't ever worked in a project that have fulfilled even one of these prerequisites. :)
    – Theodor
    Feb 16, 2013 at 13:41

Yes it is very much alive, though today it's the more common "V model" that is used.

In either case, the problem that Agile has is that the solution almost never ends, the customer can continue to request changes and the development will continue to iteratively resolve them. For a project that is based on time and materials costing, this works very well. For a project that has a fixed cost, it doesn't.

For these fixed-cost projects, the customer almost always expects pre-defined milestones to demonstrate progress, however, these are more of the formal written variety rather than working code. For customers like this, the written specifications become the project, one where the software development is a secondary consideration (as they assume, if you have a well-defined project, the software should be easy to develop). These companies are also the ones that make heavy use of cheap, outsourced development resources.

So, if you have a fixed pot of money or time, do not expect the requirements to change or are not allowed to change any requirements, and are expected to supply a strong set of written documentation, then the waterfall models are the only ones that make sense.

Agile can be introduced in the middle of these projects to do the development, but you still have a ramp-up phase where the specifications are created from requirements, and a ramp down phase where the software is installed and tested in situ. Agile doesn't respond well to these cases.

  • Agile can work very well with a fixed pot of money or time, provided that the scope isn't also fixed. The other point is that customer/contractor can choose the type of contract (T&M, fixed cost, or something in-between) to be consistent with a particular development methodology (agile or waterfall) - it isn't predetermined.
    – DNA
    Jul 29, 2012 at 22:05

To who? Most of the managers I have dealt with still use the Waterfall Software Dev Process for scheduling, and up levels seem to like it for easy of scheduling.

Practically, very few developers I know believe it works or is even valid.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.