arrow for title

Waterfall development model: its history and limits

17 Jun, 2020 Methodologies
Waterfall development model: its history and limits

Anyone who has studied software or computer engineering knows the famous Waterfall model. In this article, we will go through its history and limits.

Why the Waterfall model?

When software development became an industrial activity, an already established working model was adopted in this new field.

The Waterfall model was the one used in manufacturing: widespread in the 1970s, it has been the traditional method for “narrating” and carrying on the software lifecycle for decades.

Its phases

The Waterfall approach is marked by some steps, or phases, dealt with in a linear way:

As you can imagine, this is a consequential process: the output of a step becomes the input for the next one. In addition, the software is released only after the process is complete, once all the "steps" of the Waterfall have been covered.


Limits and difficulties

I have never seen a project developed with this model being successful.

Although I grew up on bread and Waterfall at the University, in my work experience I immediately collided with the intrinsic limits and difficulties of this process.

First of all, interdependence between the phases makes it essential to analyse the project in detail well before writing a single line of code: starting the implementation phase before all requirements are clear is highly discouraged.

What if the customer suddenly changes his/her mind, perhaps during the verification phase? Or what if you find out that what has been implemented does not reflect the requirements?

My suggestion is to run for the hills, because the only other option is the trash bin. Throw everything away and start from scratch: analyse the new requirements, draw up a new quotation, start implementing and hope that everything will work this time. And customer's expectations are met.

I have dealt with projects of this kind and they were mostly left incomplete or subject to long negotiations with the customer, in order to establish the new economic terms. Someone would certainly lose something.

The other great limit of the Waterfall process consists in the fact that the release takes place at the end of the main phases: the long-awaited moment has arrived, however, a potential change of program is no longer acceptable and therefore new requirements or requests cannot be integrated.

That is why this model no longer fits in the current world.

The "new world" of software

As we all know, the evolution of our customers’ needs is quick and sudden nowadays.

Gabriele Giaccari, my partner 20tab's CEO, always reminds me that it is actually the whole context in which software is born that changes rapidly: market needs evolve, users give us feedback on how to improve our product or mere technology advance.

Waiting for the entire cycle to end before getting feedback from our customers could cause damage in economic or general satisfaction terms which, at best, leads to the elimination of the estimated profit, but in most cases can lead to serious losses.

What approaches to take then?

The answer can be found in the 1980s, when Toyota introduced a fundamental business principle for the future: continuous improvement, the Kaizen philosophy.

Mr. Toyota did not invent anything, but led to the evolution of the outdated Deming cycle, also known as PDCA: Plan-Do-Check-Act.

Starting from there, a series of methodologies related to the idea of ​​an iterative process were developed: Lean and Agile, for instance, are methods that , at 20tab, we use in our projects and in those of our customers, thus adhering to the Continuous Improvement vision. You can learn more here!

The winning strategy promotes "renewal in small steps" and is the only one meant to win in an era like ours.

Raffaele Colace

contact us

Ambitious projects need innovative methodologies and processes. And we are able to apply them.

Shall we try?


You may also be interested: