There are many different ways that people build software. One way is the waterfall model. Waterfall is frequently compared with the more iterative and agile approaches to software development.
Waterfall is like many terms in software development, poorly defined and poorly understood. Many projects are slapped with the label of being a “waterfall” project without any true understanding of the term. Often this is done in a vaguely derogatory way.
In fact, I rarely hear anyone say good things about waterfall, so is it really that bad? And where did this waterfall method even come from?
The first informal origin of the waterfall method comes from a US Navy research paper over 60 years ago. However it may be more correct to say that the first formal description was proposed by Lockheed Martin’s Winston Royce in 1970 (PDF). Although Royce never mentioned the word “waterfall”, his paper did list the basic stages for the waterfall method.
Waterfall is a process of software development where you work through each stage of the project lifecycle for all features in full before moving on to the next stage. Broadly speaking the stages are gathering requirements, analysis, design, coding, testing and then operating the software. These stages are illustrated in Royce’s paper like so:
Each stage might be several months of work depending on the size of the project but of critical importance here is that you finish each stage for all features in full before moving on to the next stage.
Many developers and projects managers dislike waterfall because it does not easily accommodate potential changes in the project scope or direction, in essence things are fixed after each stage is completed, which can lead to huge project problems if not managed correctly.
Getting to the end of a 12 month project and discovering that your stakeholders are super unhappy with the end result is never a good position to be in, even if you take the time to kindly remind them that this is definitely what they really wanted 12 months ago! No one wins in that kind of situation. Luckily for us iterative development came to the rescue.
The waterfall method is in stark contrast with the way iterative software development works. In iterative software development you build a very small part or feature of the software and rapidly loop through all of the stages of gathering requirements, analysis, design, coding, testing and operating the software for each feature. This has the effect of building out the software piece by piece rather than as one huge monolith project.
Iterative development can be illustrated like so:
Ideally iterative development closely follows the original plan broken into small steps with a reasonable amount of room for flexibility in the project. However, as most people discover this is often not the case. Too much flexibility in your project will cause costly deviations and vastly expanded development cycles.
Take the example of a 12 month project, with 2 week iterative development cycles. Lets now consider that some of the project’s requirements change at least every 2-3 months and these additional requirements add 1-3 more development cycles to the project. With this additional work you can very easily turn a 12 month project into an 18 month project, a 50% increase in project time and costs.
I still believe an iterative and agile approach is best for most situations. A project plan that is reasonably flexible usually avoids disaster and pivots into success along the way. Iterative development has certainly been the dominant approach to software development for many years now, but I still believe waterfall has its place, particularly in larger enterprises.
When does waterfall make sense?
Many larger enterprises prefer waterfall, why you say? Well consider that a large company may have requirements which are well known after consulting with internal stakeholders and project budgets that might be shared across teams or departments and are tied to quarters or years.
It is often the case that you may have buy in from one team to sponsor one part of the project e.g. the operations team sponsors the requirements and analysis gathering stages since this information also has further use to their team and their business analysts know the best way to reach all stakeholders. Then another team might sponsor a different stage of the project e.g. marketing co-sponsors the design stage so long as the UX, branding and integrations meet the specifications for their next marketing campaign.
Each department may only have budget to spend on this project in a specific quarter and there is a process to get everyone on board in the right places and pressure deliver each stage in full and signed off before moving on to the next stage.
This is just one example of where the waterfall method of software development makes sense. The objective reality is that software is mostly built to solve problems that make or save money. The best software development methodology is always the one that helps achieve these goals in the best way possible for everyone involved.