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.

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?

share|improve this question
    
interesting question. looking forward to the answers. –  DevSolo Nov 12 '10 at 16:35
1  
Related question: Are there any major alternatives to Waterfall and Agile? –  Peter Boughton Nov 12 '10 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 Jul 19 '11 at 13:28
1  
@Yannis Rizos: why are you closing this interesting question alone, without a single community vote? –  user2567 May 30 '12 at 7:05
1  
@Pierre303 because of this question which the discussion here brought up this question. –  Ryathal May 30 '12 at 18:37
show 11 more comments

8 Answers

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.

share|improve this answer
7  
+1 on the YOUR methodology, the next Agile coach that tells me SCRUM is the only way will get a boot up the backside ;) –  Martijn Verburg Nov 12 '10 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 Nov 12 '10 at 16:46
1  
+1 for YOUR Methodology. –  Cape Cod Gunny Nov 13 '10 at 12:37
2  
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. –  Dan Neely May 29 '12 at 13:28
1  
@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 Jun 3 '12 at 19:39
show 4 more comments

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 (www.openmetis.com) 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.

share|improve this answer
5  
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. –  Eric Wilson Dec 21 '10 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 Dec 21 '10 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 Dec 21 '10 at 19:33
    
add comment

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.

share|improve this answer
6  
As per Agile Dilbert: is.gd/lDoQgb –  Peter K. Jan 10 '12 at 3:22
4  
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 Feb 17 '12 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 May 22 '13 at 13:21
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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 Nov 12 '10 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 Nov 12 '10 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 Nov 12 '10 at 20:59
    
@Hounshell, that's absolutely true. Embedded software relies more strongly on not having changes (or errors). I see I neglected that in my response. Embedded software is also usually much smaller in scope (fly-by-wire, or fire control), and the entire project could be completed in a single agile "pass." –  Stephen Furlani Nov 12 '10 at 21:00
1  
Hi Stephan, not all software requirements constantly change. –  Paul Nathan Dec 21 '10 at 1:22
show 4 more comments

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.

share|improve this answer
    
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 Jan 10 '12 at 17:51
add comment

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.

share|improve this answer
    
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 Jan 10 '12 at 17:56
2  
I can say the same of agile. Jr. developers without guidance can make a mess of agile with a quickness. –  Charles Lambert Jan 10 '12 at 19:01
add comment

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.

share|improve this answer
    
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. –  Eric Wilson Feb 17 '12 at 13:41
    
@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 Feb 17 '12 at 22:29
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.