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.
The Waterfall approach is marked by some steps, or phases, dealt with in a linear way:
- Requirements: the first phase of requirements gathering and analysis to verify their feasibility, costs, delays, etc.
- Design: the moment in which the software architecture is defined starting with analysis documents.
- Implementation: this is the actual code writing phase.
- Verification: this step concerns testing the implemented modules and integration texts, to verify the correct functioning of the entire system.
- Maintenance: this phase involves releasing the product to the customer and continuous maintenance to improve functionalities.
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 we use in our projects and in those of our customers, thus adhering to the Continuous Improvement vision.
The winning strategy promotes "renewal in small steps" and is the only one meant to win in an era like ours.