Hacker News Reader

Comment by MortenK | Hacker News Reader

Waterfall is actually considered the very best model for software development, when the requirements are known up front in excruciating detail.

An average project experience around 25% change in requirements. Hence waterfall is highly unsuited for the majority of projects, since it does not handle requirement changes well.

However, in a few areas such as aeroplane control software, space shuttle software and similar, waterfall is indeed the optimal development process.

Different projects DO require different development processes. That's not wishy washy, it's the reality of software engineering.

Mindlessly applying your favourite development process to all projects, be it waterfall, scrum, evolutionary prototyping, spiral development or what have you, will very likely result in failure, if the process does not fit the project.

View on HN

"Waterfall" was defined in a paper describing how NOT to do software development. The problem was that very few people at the time had any process at all with software so seeing this they gave it a try.

The paper you and "gujk" are referring to, I believe must be Winston Royce's paper.

It's wrong to say that the paper is a description of how not to do software development. Rather, it's suggestions for a set of improvements to the process, while retaining the sequential nature. In the paper, Royce considers waterfall to be a good process, but with flaws which result in high risks. These flaws is what he addresses in his paper.

His suggested approach is derived from pure waterfall, and is very much similar. It falls into the "modified waterfall" category of life cycle models, together with a group of other similarly waterfall-derived models.

He said, and I'm quoting, that the pure waterfall method is a good concept "but is risky and invites failure." He described how it leads to massive cost and schedule overruns. It was definitely a process that he did not think you should use.

His proposed solutions that you call "modified waterfall" are modified quite a bit. (As an aside, he never used the word "waterfall.")

The paper is here: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

I have read the paper multiple times over the years.

The quote "is risky and invites failure" is correct. However, another quote, even on the very same page:

"However, I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks."

These suggestions are to 1) Add an additional (preliminary) design phase, after requirement analysis. 2) Much greater documentation. 3) Perform the entire sequential process twice (not x amount of iterations, just two times). 4) Additional activities and documentation during testing phase. 5) Involving the customer.

His diagrams require close scrutiny, as on first inspection it seems the process is markedly different, when it is really not. It is still an entirely sequential waterfall process, just with an extra phase (preliminary design).

"waterfall" was a made up term invented in a paper to describe a hypothetical development process, not an actual process.

The term "waterfall" wasn't coined by Royce in his paper. His paper was a set of suggestions to improve what later became generally known as the waterfall process.

And Royce was ultimately advocating an iterative method (rather than a strict waterfall), not unlike most agile methods today, although his cycles were much larger.

If one is interested in software development methodology, I strongly recommend taking 15 minutes to read the actual "waterfall" paper[1].

Poor guy, Winston Royce is one of the most misunderstood folks in the industry.

(By the way, curiously enough, Royce's son William was a major contributor to the Rational Unified Process.)

[1] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

He wasn't advocating iterative methods in the agile sense, in fact he calls for "complete program design" before any analisys or coding, along with intensive documentation, planning, controlling and monitoring. An iterative approach to development drops nearly all of those.

The graphic where he shows cycles going back stages is used to exemplify failure, which he proposes to fix via the strict practices above.

Or, he could be advocating the most agile process that the technology of the time (1970) would allow. Remember that there were no desktop computers, no internet, the programming language C was just being created.

Agile processes don't depend on technology, just people, paper and communication, in fact technology can be a burden sometimes.

Just in case someone from the future misunderstands this: I don't mean that agile drops analysis, documentation, planning or monitoring (they are essential to it) but it leaves the "intensive" and "before" parts out.

Development processes very similar to todays "agile" family, existed back in 1970. "Evolutionary prototyping" for example (a member of the "prototyping" process-family), is one of the precursors for todays agile practices.

Reply on news.ycombinator.com