Waterfall Model: Build Software Like a Building

The mental model

Think of building software like constructing a physical building. You wouldn't start laying bricks before the architectural blueprints are 100% complete and signed off. The Waterfall model applies this same logic to software: progress flows sequentially and irreversibly downwards through a series of distinct phases, just like water over a fall.

How it works

The process is a strict, linear sequence of steps. First, all project requirements are gathered and documented. Second, the system architecture and software design are created based on those requirements. Third, the code is written (construction). Fourth, the completed code is tested against the original requirements. Fifth, the software is deployed. Finally, it enters a maintenance phase. The output of each phase, like a detailed requirements document, becomes the frozen, unchangeable input for the next. There is no overlap between phases.

When to use it

Waterfall is the earliest software development methodology, originating when there were no established alternatives for knowledge work. It is best suited for projects with extremely stable, well-understood, and fixed requirements from the very beginning. If the problem and solution are both crystal clear and unlikely to change, Waterfall provides a structured, predictable path to completion. Think of a project to migrate an existing application to a new server with zero functional changes.

When not to use it

Avoid Waterfall for most modern software projects, especially those where requirements are uncertain, evolving, or where user feedback is valuable. Its rigidity is its greatest weakness. If you're building a new product for a dynamic market, or any system where you expect to learn and adapt as you go, Waterfall is a poor fit. The cost of discovering a misunderstanding late in the process is prohibitively high, which is why more flexible, iterative models like Agile were developed.

One canonical example

Imagine a project to develop firmware for a simple, embedded device like a microwave oven controller. The functions are known and non-negotiable: set time, start, stop, select power level. These requirements can be fully defined upfront. The team would write a complete requirements specification, design the entire system, build all the code, and then test the final product on the hardware. There is little room for iteration once manufacturing begins.