The two predominant software-development methodologies are waterfall and agile. When discussing these two, there is often much focus on the particular practices that distinguish them (pair programming, TDD, etc. vs. functional spec, big up-front design, etc.)

But the real differences are far deeper, in that these practices come from a philosophy.

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

My question is, regardless of what you think of TDD or functional specs, is the waterfall development methodology really viable?

Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software? Or is the question really about what sort of practices work best in our situations to manage the inevitable change?

  • 1
    interesting question. looking forward to the answers.
    – DevSolo
    Commented Nov 12, 2010 at 16:35
  • 1
    Related question: Are there any major alternatives to Waterfall and Agile? Commented Nov 12, 2010 at 17:39
  • 3
    @FarmBoy - Good question. I view the agile philosophy a bit differently. I'd write it as "Agile says: Change is inevitable, so make it cheap to determine the cost of change." Change could still be very expensive, but in agile you can figure that out quickly and cheaply so that we always know the cost of change. Phrasing it the other way makes people think that since they are doing agile change will be cheap. Some changes cost a lot no matter what the process.
    – Mike Two
    Commented Jul 19, 2011 at 13:28
  • 1
    @Yannis Rizos: why are you closing this interesting question alone, without a single community vote?
    – user2567
    Commented May 30, 2012 at 7:05
  • 1
    @Pierre303 because of this question which the discussion here brought up this question.
    – Ryathal
    Commented May 30, 2012 at 18:37

9 Answers 9


Of course waterfall is viable. It brought us to the moon!

And it's a agile coach talking here!

Unless you can clearly identify problems related to the way you manage your projects, there is no valid reason to change.

As an alternative of Agile and Waterfall methodologies, I will suggest YOUR methodology. Adapted to your specific business, your specific team, your products, you way of working, your company culture... It's why Scrum is called a simple framework instead of a methodology.

Wanting to implement a methodology because someone on a blog you like talked about it is as stupid as letting problems going without doing anything.

  • 10
    +1 on the YOUR methodology, the next Agile coach that tells me SCRUM is the only way will get a boot up the backside ;) Commented Nov 12, 2010 at 16:43
  • 1
    @karianna: I do specifically SCRUM, but sometimes, it's just not appropriate. On the other hand, I also seen team trying to sell SCRUM to their bosses thinking it will solves their problem. They failed because the problem weren't their bosses or their PM. There is no single rule. Each case its solution. And yes, most organisationnal problem can be solved with agile techniques, but agile is not a silver bullet.
    – user2567
    Commented Nov 12, 2010 at 16:46
  • 5
    Not just the moon. The space shuttle had ~1M lines of C code in its embedded systems. Over ~30 years they only had 2 bugs make it into production builds. Commented May 29, 2012 at 13:28
  • 2
    Waterfall also KILLED the first three astronauts. This insistence on using this Apollo program as a poster child for Waterfall is ignorant at best. Waterfall is also cited as responsible for both programs being complete financial boondoggles, and the Shuttle being an over-engineer, fragile, expensive "space ferrari" when the original spec was for a "space truck". I am pretty sure SpaceX would disagree about Waterfall.
    – user7519
    Commented May 30, 2012 at 23:18
  • 4
    @DanNeely the high quality level of the space shuttle software was not cheap. Apparently the price was in the size of $1000 per line of code.
    – user1249
    Commented Jun 3, 2012 at 19:39

You begin by saying:

The two predominant software-development philosophies are waterfall and agile.

This is false. This dichotomy has been constructed by the agile community in order to create an opponent against which to position themselves. Before agile was in vogue, people used to speak about a myriad of different approaches to building software. They still exist today, but somehow they are often lumped together into a big mess called "waterfall" by agile proponents.

I have been using OPEN/Metis and its variants for over 10 years with great success. It is definitely not agile, and definitely not waterfall. Thousands of developers create extremely complex software for aircraft, life critical systems, banking, etc. using non-agile methods every day.

So yes, of course there is a viable alternative to agile.

  • 7
    I'm not able to quickly understand what OPEN/Metis is from that link. (Usually you don't need to download a methodology.) My question is: what is it's philosophy, particularly in dealing with change? Does it attempt to minimize change, or to reduce the cost of change? Bear in mind that my question was about agile philosophy, not about agile practices. Commented Dec 21, 2010 at 13:28
  • OPEN/Metis has an iterative lifecycle that builds systems incrementally. Change is acknowledged as something that not only happens, but something that is great when it happens, since the very purpose of the development of an information system is to effect some change. The cost of change, however, is controlled and managed through an appropriate lifecycle and associated practices.
    – CesarGon
    Commented Dec 21, 2010 at 19:32
  • 1
    Regarding your remark about "downloading methodologies", well... you don't download methodologies, I agree. You download documents that describe methodologies. Otherwise, how do you learn about them? Look at the myriads of books that describe XP, Scrum, etc.
    – CesarGon
    Commented Dec 21, 2010 at 19:33
  • 1
    @CesarGon Too paraphrase Cheece and Chong: "looks like Agile, smells like Agile, feels like Agile, tastes like Agile; must be Agile ..."
    – user7519
    Commented Jun 3, 2012 at 22:07

First, I'm going to disagree with your statements:

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

My interpretation is:

Waterfall says: The customer knows what they want.
Agile says: The customer doesn't know what they want so we're going to have to make a few different versions.

The best implementation of "waterfall" that I've ever seen was a huge integration project with a very large financial customer and there were about 40+ sub-projects involved. The desktop and website package we supplied was just 1 of those 40+ sub-projects. While I thought they blew through other people's money rather excessively, they had their stuff together and kept 40+ different ships all moving together in formation. The project went live on the target date (the target moved once during the project) and while I thought they could have done it more frugally and agily, it got done on time and on spec. The go-live night's schedule was about 100 pages long and about 40 of those pages were emergency panic contact details of all sorts of people involved. I was very impressed by this client.

Or, you could do what we do, which is run around and do what the most recent complaint/bug report is, and call that agile.

  • 8
    As per Agile Dilbert: is.gd/lDoQgb
    – Peter K.
    Commented Jan 10, 2012 at 3:22
  • 11
    It's more like "Waterfall says: The customer doesn't know what they want so let's sit down, talk it over and agree on what they want before we start hacking at it"...
    – scrwtp
    Commented Feb 17, 2012 at 11:19
  • +1: Very good answer. I think the agile community have one basic problem: agile is good in certain contexts for certain classes of projects and customers, but they fail to see that there are projects in which the requirements do not change that fast and more structured approaches are a better choice. I think that the agile community should try to realistically identify the areas in which their approach is a better choice (I think such areas exist) and not try push it as a general solution, because it is not.
    – Giorgio
    Commented May 22, 2013 at 13:21
  • 6
    @scrwtp - and Agile is more like "My customer doesn't know what they want, and can't/won't talk and think it out, and they change their mind every 5 minutes. I have to shove something in their face to get any meaningful answers". Wow. That sounds really unfortunate when I write it down. Commented May 2, 2014 at 13:39
  • 1
    @scrwtp: I think the million dollar question is: is that "belief" that you can "sit down and talk it over and agree" viable? The answer is: it depends, right? It depends on a number of variables: how big is the project? Do we even KNOW how big it is? How much time do customers have to "sit down" with us? We've tried for decades to relate software development to construction, which is almost 100% prescriptive. Software development is somewhere in the middle between "wholly reactionary" and "100% prescriptive". In most shops, it's closer to "wholly reactionary", hence agile's adoption.
    – Calphool
    Commented May 2, 2014 at 14:54

Yes, various software development techniques are all viable depending on your problem domain. It's "Horses for Courses".

For example, you're writing software to control a Nuclear power plant or to drive the NASA space shuttle. This sort of problem domain is probably better suited to a waterfall (or even stricter) approach, you want to sort out all of the issues up front if possible (or BOOM!).

Building the latest web 2.0/3.0/buzzy marketing term UI? Agile is a much better way to go (yo need that quick feedback and change).

There are what I would call software craftsmanship principles that can still be applied no matter waht the methodology is e.g:

  • Source control
  • build and CI
  • pair programming
  • TDD
  • I give a ^%$$&

and more.

Whatever you do, don't listen to the zealots on either side of the equation, do what's right for you, your team and your problem domain.

  • Waterfall works if you can afford it. Somebody above claimed that the NASA moon project software cost was roughly $1000 per line of code. Most shops need something like $1–10 per line of code and agile is better for that kind of situations. However, I do not pretend that agile provides better quality overall. It basically boils down to can you afford to page lots of money to be pretty sure the software is correct or is it cheaper to figure out the solution once you find out that the software is not correct. Commented Dec 4, 2017 at 11:02

The problem stems from the complexity of software. Waterfall works great for things like bridge building and road paving because physics just never changes. Sure, at some point we'll develop a new asphalt but it won't revolutionize the way roads are built. The steel in a bridge's suspension is either the right size, or it isn't. You can't kludge or stub a real construction project like you can with software.

Software changes. Software changes rapidly. Moore's law states that number of transistors on a chip doubles every 18-24 months. In corollary, the number of lines of code in a program also doubles. Complexity in between those lines of code therefore increases with a bigO of something like 2^(2t).

Software changes rapidly, and complexity increases exponentially with it.

When controlling the cost of the software, you want to control exponential factors, not just multiplicative or additive. Changing code increases the complexity (and gets exponentially more complex itself as the project moves on) in an exponential manner.

Change is inevitable. The very nature of programming extends the language with classes and custom methods, thus changing the language itself. You can't do that in any other kind of engineering discipline (like building roads. You don't invent new pavement just to pave a road in kansas over california).

The agile method also gives you a platform for handling future releases and bug fixes. You alredy have the management tools, processes, trained employees, for developing versioned software. With a waterfall method, you would need to retrain your team to handle even minor bug-fixes.

anyway, my 2 cents.

  • 2
    There are a lot of aspects of software design that are as absolute as the laws of physics. Agile is a tool just like waterfall or other methodologies, and as other people posted there are a lot of business cases where it does not make sense. I would be surprised if I saw you in line to get on an airplane where Boeing said they were in the middle of an agile process on the flight control software and they needed customers to iterate on whether the plane doesn't flip in midair for no reason.
    – Hounshell
    Commented Nov 12, 2010 at 20:55
  • And just to shotgun more holes in your argument, there are road designs being engineered right now that would be appropriate for a road between Kansas and California, but not between New York and Boston. And new techniques for handling asphalt are coming out all the time.
    – Hounshell
    Commented Nov 12, 2010 at 20:57
  • 2
    And lastly, you say "With a waterfall method, you would need to retrain your team to handle even minor bug-fixes." That's just so ignorant of how the waterfall process works. You should try out a good waterfall shop before you grandstand about how it's inappropriate for every software development scenario.
    – Hounshell
    Commented Nov 12, 2010 at 20:59
  • 1
    Hi Stephan, not all software requirements constantly change. Commented Dec 21, 2010 at 1:22
  • 1
    Business always changes; a business that is not changing and adapting is a business that is dying. Time is a constant, which doesn't interact with change well. A system that has the philosophy that acknowledge Change is expected can accomodate the change, otherwise, Time has to accomodate change, and it is an unyeilding constant!
    – user7519
    Commented May 30, 2012 at 23:09

To answer the question, is there a viable alternative, for software perhaps not - or not yet, at least in the general case. I think it comes down to the nature of software. Software, being information, can be duplicated for free. Unlike a bridge or a house. This means, with practice, I could get good at building a house and be operating in a relatively simple domain. At which point why not use a one-shot approach?

But because software has zero duplication costs, why would you ever do the same thing twice? Software tends away from manufacturing. So if all software is the creating of new product then we're always operating in a complex domain where, to some extent, we don't know what we're doing. Or it's expensive to know up front and it's cheaper to find out by doing. In a complex, risky domain, I'd want to try experiments and increment and iterate.

Nuclear power stations and fly-by wire systems are often given as examples of software you'd want to do waterfall. But wasn't the shuttle avionics system developed iteratively? As was the Canadian and US air traffic control systems?

And if OPEN/Metis is iterative and incremental then, for me, it sounds like it has the agile philosophy even if it doesn't associate itself with other common agile practices.

  • 2
    So now agile is trying to take credit for iterative and incremental? Never mind that iterative and incremental have been CORE parts of waterfall development since I started development in '92.
    – Dunk
    Commented Jan 10, 2012 at 17:51

The Waterfall method most certainly is viable and is as philosophically sound as any other approach. Remember that Waterfall has been around much longer than Agile, but note that this isn't an argument to state whether one methodology is better than another.

You use the Waterfall method when have a very clear understanding about the entire problem domain and what the customer wants to achieve in a software package. You've probably quoted a fixed price when taking on the contract, and your customer understands that they cannot deviate from any agreed requirements. Your process is strictly one that flows through a series of sign-offs between the various stages of development, and it is often the case that each stage is completed by a different team - sometimes even a different company - each of which may not necessarily in contact with the others. You often see Waterfall applied to good effect in military and government projects when they are tendered to outside contractors. Where Waterfall and other similar approaches get a bad reputation is when developers run into problems, such as poor estimation, schedules planned without contingency time, or a poor or incomplete understanding of the problem domain. The issue is never truly a fault of the methodology, but in the application of it.

The comparison between Agile and any methodology is a false one. Agile isn't a methodology, it's a philosophy, or perhaps it would be better to say that it is an umbrella term that represents a different way to look at how you go about developing software. A methodology is merely a tool, and as such its value will always be less than the individuals and interactions that are at the heart of what it means to be Agile.

Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?

Every opportunity to minimize change is valuable to both the developer and the customer. Changes can cause a schedule to slip, or features to be left out in order to meet a schedule. It's how you manage the effects of change that impacts on the value of your projects.

Or is the question really about what sort of practices work best in our situations to manage the inevitable change?

Your practices may aid in the management of change, or they may ignore change completely. What matters is the combination of your development practices, and the management of your relationship with your customers, and whether these things work together effectively for all of the parties involved.

Those of us who are for all intents and purposes Agile understand that you choose a method that works for you. If you like particular approach, follow it. If it doesn't quite fit your needs, change it. How you go about crafting software really comes down to trying to make the best use of the resources you have at hand, and minimizing those practices that can lead your project towards failure, and you often find that you need to change your method to suit the particular project at hand.

It really is one thing to say "Ok, so now we are Agile", and totally another to actually live and work by the philosophy that Agile is. Whether you use Waterfall, Incremental, Spiral, SCRUM, XP, FDD, or any other method, you are basically Agile where you value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

and where you bring your tools, method, and your experience all together in order to apply these values successfully.

  • 2
    Wow. There's just so much strange stuff here. Waterfall is viable on the basis of being around longer? Waterfall is justified on the basis of use in defense contracts? Is every opportunity to minimize change really in the customer's best interest, or does it lead to delivering what he thought he wanted rather than what he actually wanted? Since you seem to care about this, I've tried to understand where you are coming from, but I'm missing something. Commented Feb 17, 2012 at 13:41
  • 1
    @EricWilson Waterfall has been around longer and used successfully long before the Agile philosophy was discussed. It is viable because it exists and when applied properly works for those who wish to use it. I did not justify its use, but merely pointed to an example where I've had personal experience where I've seen it work, and yes, I've seen a few spectacular failures too. You don't look for opportunities to minimize change, you want opportunities to introduce change, but you need to do it sensibly, otherwise your customer either gets less than they wanted or a slipped deadline.
    – S.Robins
    Commented Feb 17, 2012 at 22:29

Yes, Waterfall, Spiral, Iterative and other hybrid process models are all viable, but change is inevitable. Process is more than just about how to handle change, and (I claim that) the biggest determinant is how well you know/understand the problem, and how accurately you can plan and predict.

Stating that "the two predominant software-development methodologies are waterfall and agile" is disingenous, as there is a spectrum of software development processes, and many companies synthesize their own version of the process model, often changing for a given project. There are more than two viable approaches to software development. Although Waterfall and Agile tend to fall on opposite ends of the "change" spectrum, it is reasonable to typify these competing methodologies as,

Waterfall says: Change is costly, so it should be minimized.

Agile says: Change is inevitable, so make change cheap.

But that is not the whole story. Business needs to be able to plan and predict, but software is a creative process, and estimates are often wrong. Remember the good - fast - cheap triangle? Add a fourth dimension, process, and you find that reducing process effort can also compress the schedule, when the estimates turn out to be wrong and a project is in danger of delay. Software is a fungible (mutable) process, and Agile, Iterative, Spiral all offer the ability to deliver incremental functionality in shorter intervals.

Waterfall and other requirements driven process models have controls for handling change, so it is inaccurate to say Waterfall minimizes change, it is more accurate to say Waterfall recognizes and manages change, and communicates the impact of that change (because change causes schedule impact when you have requirements and design up front). When you are building a product, or have need to fully-define requirements (functionality), you are driven to one of the hybrid models.

And when estimates are wrong, often process (the fourth leg of the iron triangle) is sacrificed to meet the schedule.

  • I wasn't disingenuous. After five years of development in a variety of companies, I've only encountered two, and one is only named as a perjorative. Spiral? Never heard of it. Commented May 2, 2014 at 17:27
  • I meant that I hadn't encountered them in the real world. All sorts of things are out there on the interwebs, but I'm not going to start hunting them down now just because I happened to ask a question back in 2010. Commented May 3, 2014 at 11:10

Mature agile and waterfall approaches are indistinguishable from each other. Your assumption about the goal of the waterfall approach is incorrect. They both have the goal of producing quality software. When you don't have a solid development approach for the company as a whole, you need to look at which approach will provide the least amount of friction to adoption. In the end short development cycles, a solid QA team, and a business that drives the development are what is most important to producing top notch software.

  • 1
    I would put a caveat to your comment. Waterfall requires talented people or it will fall flat on its face. Learning to design well is hard. Learning to code is comparatively very easy. IMO, that's the main reason most developers seem to prefer agile.
    – Dunk
    Commented Jan 10, 2012 at 17:56
  • 4
    I can say the same of agile. Jr. developers without guidance can make a mess of agile with a quickness. Commented Jan 10, 2012 at 19:01

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