The Origin of Waterfall Methodology

The Origin of Waterfall Methodology

The Waterfall method of software development is well known and widely spread all over the world and is often – wrongly – mentioned in a disparaging manner.

However, most software development projects are completed using waterfall because the defining charactertistic of waterfall is that it is sequential.

Currently, Waterfall is considered the traditional methodology of software development and old fashioned when compared to the new Agile dog on the block

The Waterfall methodology is largely attributed to “the Royce paper” by Winston W. Royce in a 1970 paper with aspects of the conceptual process go back to at least a 1956 paper by Herbert W. Bennington.

Interestingly, neither papers mention the term waterfall and argubly are far more flexible than the rigid methodology now associated to them (that’s for another post!) and when hardware development method was applied to software creation it was seen at the time as innovational as the software itself.

The Origin of Waterfall Development

How things change!

During this period software development followed the typical manufacturing process with strict documentation, large teams and sequential stages.

And the key things to note here is that the customer, their feedback or their actions do not participate in Waterfall projects and the development is sequential broadly broken into normally five stages as follows; documentation, design, implementation, verification, and maintenance.

Wikipedia_Waterfall
Wikipedia_Waterfall

If you understand those two attributes you’ve nailed Waterfall and you can now move on with your life, see, it’s sequential…

The client, the end customers and the market was and still is researched before development starts to learn his demands and vision of the required software.

This is documented often called a Specification and then transferred into a “Statement of Work” to plan and create the features of the software product and the customer sees the product only after it is finished.

The criticism is that developers and teams working using a waterfall methodology cannot return to the stages that have already been completed.

Fundamentally, to fix something – or to change direction or key product features – the team has to run the project from the beginning.

Recap

  • Waterfall is sequential
  • It normally has 5 stages
  • The customer is consulted before but not during and only sees the product after it’s finished
  • To fix or change something you have to run start the project again (or a mini version)

Factoids

  • Waterfall as a concept was developed in the 50’s by Herbert Bennington and then largely attributed to the “Royce Papers” by Winston Royce in the 1970s
  • The term waterfall was never mentioned in either of these sources
  • Ironically, the life cycle production process outlined by Royce was far less rigid than what is now projected onto “Waterfall” methodology.

Congratulations you are now are a waterfall expert, and can serve up some nuances to impress the meeting room or any recruiting manager who challenges your knowledge of “agile vs “waterfall”