[leelin]

For the MIT alums out there, I remember a 6.170 exam that had the question: "When is it appropriate to use the waterfall model of development?"

The answer was any time you are developing software for the government! The professor specifically mentioned it in lecture once, so that alone was enough for full credit on the question (other reasonable answers were fine too).

Later I TA'ed the class twice and made sure to eliminate these pure lecture-attendance-check questions.

[mbesto]

Interesting fact - the original design of "waterfall" isn't what we perceive as "waterfall" today: http://leadinganswers.typepad.com/leading_answers/files/orig...

My theory - agile/iterative development rarely gets sold because we continue to believe we aren't susceptible to planning fallacy.

[svachalek]

What do you perceive as waterfall? That's exactly the way we learned it in school...

[bpyne]

Much of our industry believes Waterfall means a single-pass development process. Dr. Royce explicitly said to do it twice. (It was a military officer who later took the process and made it into a single pass.)

If you learned it as a two-pass process, then you learned it correctly.

[zb]

This is simply historically incorrect. Waterfall means a single pass by definition.

Royce described the pre-existing state of the art - the single-pass model (Waterfall) - and suggested a modification to a 2-pass model. (This can be seen as a precursor to Boehm's n-pass Spiral model.)

To suggest that the single-pass model was invented later as a corruption of Royce's paper is nonsense. Virtually all software was developed this way both before and after the paper.

What is odd is that the earliest and most commonly cited reference to the Waterfall methodology is a paper that explicitly says that it doesn't work. Let this be a lesson on not burying the lede.

[bpyne]

In the version of the paper linked earlier in the forum, I take the following to mean two passes: build a model and then use lessons learned to build the final product. But it's a matter of interpretation and semantics. My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation. I think we can agree that Royce did not mean our modern "Agile" approach.

"If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned."

At least 2 methodologies existed before Royce's paper as described in this paper: Waterfall and "iterative and incremental".(http://www.craiglarman.com/wiki/downloads/misc/history-of-it...)

Note that, in the section referencing DoD-Std-2167, the author of the DoD standard does state explicitly that he understood Waterfall to be one-pass. Certainly he implicitly promoted it as such.

[zb]

The mistake I believe you're making is in assuming that because most people reference Royce's paper for a description of Waterfall, that means that the definition of Waterfall is whatever the main subject of that paper is. This does not follow.

The paper describes a number (more than 2) of possible models. The main subject of the paper is probably the "2-pass waterfall" diagram in Figure 7. However, when people refer to this paper in the context of the Waterfall model, they mean Figure 2. The Waterfall model is called the Waterfall model because Figure 2 looks like a waterfall, with the water never flowing uphill.

Figure 7, however, was largely ignored. (Though Brooks later recapitulated it as "Build one to throw away; you will, anyhow". I don't know whether it was influential in the development of the Spiral model or not, though it seems like a logical progression.) As far as I know this model never even got a name attached to it. Its influence pales in comparison to Figure 2, which was the first and best published reference to a design process that almost everybody accepted as "ideal" at the time.

Note that when Brooks tells the story in The Mythical Man-Month about making the mistake of getting a large group of mediocre engineers to write specifications instead of giving the job to a small group of elite engineers because he didn't want the larger group just sitting on their thumbs for a year, this was all happening in the mid 60s. Here's another contemporary quote:

The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job. —Doug Ross, 1968

Winston Royce did not invent the Waterfall model in 1970, he was just describing the already-dominant paradigm as a prelude to proposing something different. The model had been around forever, Royce provided a convenient diagram (Figure 2!) in the course of trying to critique (or even replace) it, and the name "Waterfall" got attached later.

> Note that, in the section referencing DoD-Std-2167, the author of the DoD standard does state explicitly that he understood Waterfall to be one-pass.

Of course he did, and he understood it correctly. The thing he didn't understand was that it was a terrible idea.

Had he (properly) read Royce's paper, he would have seen that it actually advocated a slightly better (but still pretty terrible) idea, but that idea was not and is not the Waterfall model. The Waterfall model is the one in Figure 2 that looks like a waterfall. Hence the name.

> My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation.

Um, OK then.

Thanks for the link though, it was really interesting.

[walshemj]

I always thought waterfall was inherently iterative you could jump back up the stack at any point in the process one sucsessfull project I worked on at BT (management system for the Uk's SMDS network) had several instances of going back and redoing stages before we even got to the final development phase.

[zb]

Have you ever seen water jump back up a few stages of a waterfall? (Hint: no.) It's called the Waterfall model exactly because that kind of thing is explicitly not part of it (see Figure 2 in the Royce paper linked above). That's the whole point of the name.

It goes without saying that no software development effort has ever lived up to this standard. Nonetheless, the fact that it is not possible to develop non-trivial designs (for software or anything else) like this in no way prevented people from advocating it as the "ideal" design process.

[mbesto]

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[4][5] although Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.[6] This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.

http://en.wikipedia.org/wiki/Waterfall_model

[bpyne]

You're being a bit too literal. The name came from the resemblance of a diagram in the paper to a waterfall. The name wasn't meant to constrain the methodology to strict characteristics of a waterfall. The steps are meant to be followed in order. It is gated. But, nothing constrains the steps from being repeated. That is the crux of the difference between Dr. Royce's paper and what the military formed as a standard based on the paper.

I took a college comp sci course a few years ago. The professor talked for a few minutes about the Waterfall methodology. In short, she said "we in academia gaffed by promoting the Waterfall methodology for several decades. It's now cause for laughter in academic circles when someone proposes the Waterfall method for software development."

[JanneVee]

One case I've heard is when you don't have any changing requirements and the domain is well known. E.g. engine control software.

[derleth]

If the requirements don't change and the domain really is well-known, why are you writing new software? Why isn't there pre-existing software you can reuse?

[mcpherrinm]

Because you can save a quarter cent per unit by changing microcontroller vendors, but you have to use a new programming language for the new one?

Because you are involved in a lawsuit with the contractor that produced your previous version and using it would possibly be an admission it met requirements, even if your in-house developers had to completely rewrite it to make it safe?

Because new safety regulations mean you have to use a FIPS approved compiler and testing procedure?

Because it's a niche product and the only people in the world who know the problem domain work for you?

[JanneVee]

If you are designing a new car engine there isn't always of the shelf software already designed and tested. There are instances like the Ariane 5 maiden flight[1] where Ariane 4 software was reused.

[1] http://www.di.unito.it/~damiani/ariane5rep.html

[Proleps]

Because it doesn't exist yet.

[peterjancelis]

Not in my backyard syndrome.

[cfinke]

You mean Not Invented Here.

[scotth]

I kind of like Not In My Backyard as an opposite to NIH.

[mryan]

They are not synonyms - NIH is correct in this case. NIMBY means something rather different.

[hackula1]

The government will often request an RFP that basically entails doing the entire project so that the vendor can do the 5 minute demonstration to show that they are capable of completing the project. This greatly inflates prices, since the stakes for the vendors are so ridiculously high.