Waterfall and the Sequential Mindset

The oldest way to organize software work is also the most intuitive: do the phases in order, finishing each one completely before starting the next. Gather all the requirements, then do all the design, then write all the code, then test it all, then release. This is the Waterfall model.

The name paints the picture: like water flowing down a series of steps, work moves in one direction, from each phase down to the next, and doesn't flow back up. You sign off on a phase, then you're in the next one.

Picture building a house from a blueprint that can't change once the foundation is poured. Plan everything, then build exactly that. It's orderly and easy to explain — and it assumes you knew everything you needed at the start.

How Waterfall Works

Each phase produces a document or deliverable that's reviewed and approved before the next phase starts. Requirements are written down and signed off; then designers work only from that signed-off document; then developers build only from the approved design. The appeal is control and predictability: at any moment you know exactly which phase you're in, and there's a paper trail for every decision.

Where It Shines

Waterfall genuinely fits some work: projects where the requirements are fixed, fully understood up front, and unlikely to change. Building software to a government contract, or embedded code for a medical device that must be certified, can suit a sequential approach — the rules are known in advance and changing course midway is costly or forbidden. When you really can specify everything correctly at the start, Waterfall's order is a strength, not a weakness.

Where It Breaks

The trouble is that most software isn't like that. Requirements change, users surprise you, and you rarely know everything up front. Waterfall's fatal flaw is timing: because testing and real use come at the very end, you discover your biggest mistakes when they're most expensive to fix — the far-right, steep side of the cost-of-change curve. Months of work can be built on a misunderstanding that nobody catches until the end.

Its Lasting Influence

Even though most teams have moved on, Waterfall's vocabulary is everywhere. The phase names — requirements, design, implementation, testing — come straight from it, and even fast Agile teams still do all of those activities, just blended and repeated instead of strictly in sequence. Understanding Waterfall is understanding the baseline that everything since has been reacting to.

Imagine the Cadence team had built the whole app Waterfall-style: a year of planning, designing, and building every feature, then one big launch. They'd have discovered only at the very end that users desperately wanted reminders — far too late to add cheaply. That painful "we built the wrong thing and found out last" is exactly the failure the next topic's approach was invented to avoid.