Waterfall

Waterfall is a sequential software development methodology in which progress flows steadily downward through distinct phases — conception, analysis, design, construction, testing, deployment, and maintenance — with each phase completed before the next begins. Formalized in descriptions of software process in 1970, it treats requirements as knowable up front and change as something to be controlled rather than expected. It is the classic counterpoint to iterative and agile approaches.

• Sequential phases - Work moves in one direction through fixed stages, with each stage’s output feeding the next.
• Up-front requirements - Requirements and design are settled early, on the assumption they’ll remain stable through delivery.
• Heavy documentation and gates - Phase boundaries act as review gates, producing detailed artifacts that hand off between teams.
• Predictable but rigid - Strong for well-understood, fixed-scope work; poor at absorbing change discovered mid-project.

In API operations, Waterfall thinking is where a lot of legacy API programs still live — the API is designed once, documented, shipped, and then rarely revisited, which is exactly how contracts drift out of sync with implementations. Most of the modern practice I write about pushes the other way, toward a design-first, iterative loop where the OpenAPI contract evolves alongside the code. Waterfall is worth understanding precisely because recognizing it in an organization explains so much about why change, versioning, and governance are hard there.