The Problem with the Waterfall software development model

The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall).

It should be readily apparent that the waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

And here is the main problem with the pure waterfall model: it’s obsolete and was not really a good model for software development in the first place; it was just easier to use already existing practices from other areas at the very beginning, but those areas were not so similar to software devlopment as initially thought.

The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected.

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model:  time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation.

The waterfall model is a bad idea in practice because it is impossible for any non-trivial project to get one phase of a software product’s lifecycle perfected before moving on to the next phases and learning from them.

Another criticism revolves around the model’s implicit assumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation. Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model.

Again, software devlopment is not like manufacturing a car or building a house: it’s more an art, like a chef creating a new cooking recept: you need to try and iterate, adding salt or sugar, tasting and sometimes to start over.

In response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model, mostly introducing overlapping phases (you don’t need to have completed one phase before passing to hte next one) or feedbacks.
But the real changing model came with the agile and iterative models.

Next: when to use a waterfal model and when an agile one.

6 thoughts on “The Problem with the Waterfall software development model

  1. Pingback: Definition Assignment 1.3 – English 301 Technical Writing

  2. Pingback: The waterfall model | Intensificación en Ingeniería del Software

  3. Pingback: Agile or Waterfall? « Look back in respect

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s