Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  thursdaysgeek Mar 9 '12 at 20:38
1  
@thursdaysgeek I have experienced it, and I'm not saying it's dead, I'm asking if it's dead. It seems to me that it is dead/dying and I'm trying to confirm that hunch through this social media outlet. :) –  CFL_Jeff Mar 9 '12 at 20:41
9  
It's not dead. It's just not the current fad/trend/"acceptable" –  Paul Mar 9 '12 at 20:45
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 '12 at 20:54
2  
@FrustratedWithFormsDesigner I think I should just stop chasing waterfalls, and stick to the rivers and the lakes that I'm used to. –  CFL_Jeff Mar 9 '12 at 21:29
show 6 more comments

6 Answers

up vote 11 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
2  
Not sure what the difference is between the "mythical" waterfall process and the "real" one. Will you please explain this? –  CFL_Jeff Mar 9 '12 at 20:43
5  
Often the Waterfall process described by Agile proponents is a strawman en.wikipedia.org/wiki/Straw_man –  jfrankcarr Mar 9 '12 at 20:49
1  
@CFL_Jeff agilites usually use the waterfall method like what you have linked, however they ignore any part of change management that would be going on in a real software development scenario. –  Ryathal Mar 9 '12 at 20:52
5  
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. –  Robert Harvey Mar 9 '12 at 23:04
3  
-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. –  Stargazer712 Mar 10 '12 at 14:48
show 3 more comments

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.

share|improve this answer
add comment

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.

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

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.

share|improve this answer
    
+1 for Agile isn't suitable to fixed price. –  Joel Brown Mar 11 '12 at 12:31
    
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 '12 at 22:05
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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