Waterfall

The sequential / phased methodology. Requirements → Design → Implementation → Verification → Maintenance. Once you finish a phase, you don’t go back (in theory).

Modern interviews ask about Waterfall mostly to understand whether you know when it’s appropriate (answer: rarely, but the rare cases matter).

The classic phases

Requirements
       ↓
   Design
       ↓
Implementation
       ↓
 Verification
       ↓
 Maintenance

Each phase produces formal deliverables that feed the next:

Requirements → Requirements specification document.
Design → Architecture + detailed design documents.
Implementation → Code.
Verification → Test reports, acceptance documents.
Maintenance → Production operation, bug fixes.

The “no going back” rule is the famous part — and the famous failure mode. In practice, all Waterfall projects have feedback loops; what varies is how formally and painfully.

Origin — Royce 1970

The Waterfall model traces to Winston Royce’s 1970 paper. Often missed: Royce described it as a flawed approach and proposed iterative alternatives. The “Waterfall” reading became dominant anyway, especially in government/defense procurement.

The lesson: dogmatic Waterfall predates Agile’s critique of dogmatic Waterfall by 30 years. Royce already knew.

When Waterfall makes sense

There are genuine cases:

Safety-critical certification

DO-178C for avionics, IEC 62304 for medical devices, IEC 61508 for industrial safety — these standards require formal upfront design, traceability from requirements to test cases, signed-off phase reviews. Modern certification standards accept some Agile flavors (DO-178C allows iterative development), but documentation requirements push the work toward Waterfall-like flows.

Government / defense procurement

Fixed-scope, fixed-budget contracts. The contract IS the requirements doc. Changes require contract modifications. Agile’s “respond to change” doesn’t fit because the change-control gate is legal, not technical.

Hardware-software co-development

You can’t iterate on the hardware. The PCB is laid out, the molds are cut, the chips are taped out — those decisions lock in 6–18 months early. Software has to follow that cadence.

Construction-adjacent projects

Software for infrastructure, building management, etc. where requirements are stable, integrators want specs, and the cost of late changes is genuinely high.

Pure compliance / regulatory implementations

“Implement these 200 rules from the new tax code.” Requirements are external, fixed, and audited. Iteration adds no value.

Migration projects with known target

“Migrate this legacy COBOL system to Java with identical behavior.” The requirements are the current system’s behavior. Discovery is bounded.

When Waterfall is wrong

Almost everything modern software does:

Product development where you discover what users want by shipping.
Anything where the customer’s needs evolve.
Anything where technology evolves during the project (typical 12+ month projects).
Anything where competitive pressure rewards fast iteration.
Internal tools, B2B SaaS, consumer apps — basically all of consumer/web/mobile.

The bet of Waterfall: requirements are knowable upfront, costs are predictable. For most software, both are false.

Hybrid: Waterfall on the outside, Agile inside

A common pragmatic pattern, especially in government / regulated work:

[ Contract / Requirements Phase ] — Waterfall, formal docs
            ↓
[ Implementation Phase ] — Agile / Scrum inside, 2-week sprints
            ↓
[ Certification / UAT Phase ] — Waterfall, sign-offs
            ↓
[ Maintenance ] — Kanban / continuous

The outer contract structure looks Waterfall (phases, sign-offs). Inside Implementation, teams use Scrum/Kanban for the actual work. Best of both: the customer / regulator gets formal documents and predictable phase gates; the team gets iterative development.

This is the dominant pattern in enterprise and government Agile.

The V-model

A close cousin of Waterfall, common in regulated industries:

Requirements ────────────────── Acceptance Testing
       ↓                              ↑
   System Design ──────── System Testing
        ↓                       ↑
   Detailed Design ───── Integration Testing
            ↓                 ↑
       Coding ─── Unit Testing
              ↓ ↑
           (code)

Each design phase on the left corresponds to a testing phase on the right. Test cases are derived from the design at the corresponding level. Strong traceability.

Used in automotive (ISO 26262), aerospace, medical. Same conceptual model as Waterfall but explicit about how validation maps to design.

Common Waterfall antipatterns (the famous failure modes)

Big design upfront (BDUF)

12 months of requirements + design. Customer’s needs change. Project is wrong from day one.

Late integration

Components designed and built in isolation; integration is the last phase. Discovers all the interface bugs at the worst time. Modern hybrid: continuous integration even within phased projects.

Documentation as the goal

The deliverable becomes the spec, not the system. Hundreds of pages, signed off, then code drifts from it. The spec ages worse than the code.

Phase gates that don’t actually gate

“Design phase is done” but design isn’t really finished. Coding starts; design is patched in parallel. Worst of both worlds.

Change-control hell

Every requirement change goes through a change-control board. Delays cascade. The team becomes change-averse for survival, rejecting valid late insights.

When you’d advocate Waterfall in an interview

For senior roles, interviewers may probe: “describe a project where Waterfall would be appropriate.”

Good answers acknowledge the genuine cases:

Safety-critical certified software (medical, aerospace).
Fixed-scope government contracts.
Hardware-software co-development.
Pure compliance implementations.

Bad answers blanket-defend Waterfall as “more disciplined” or “what serious engineers do.” Most interviewers will read that as inflexible.

Strong answers note the hybrid pattern: external Waterfall framing for contract / certification, Agile inside for the actual build.

Common interview confusions

“Waterfall is for old companies; Agile is for startups.” — Waterfall is for certain types of projects, not certain types of companies. Aerospace, medical, defense use Waterfall regardless of company age.
“Royce invented Waterfall.” — Royce described it and argued against it. The dogmatic reading came from procurement officers, not Royce.
“Hybrid means broken.” — hybrid is often the right answer. Waterfall framing + Agile execution is the dominant pattern in regulated work.

Interview angle

“What is Waterfall?” — sequential phased methodology: Requirements → Design → Implementation → Verification → Maintenance. Each phase produces deliverables that feed the next; phases don’t backtrack (in theory).
“When is Waterfall appropriate?” — safety-critical certified software (avionics, medical), fixed-scope government contracts, hardware-software co-development with long lead times, pure compliance implementations, migrations to known target.
“What’s wrong with Waterfall for product development?” — assumes requirements are knowable upfront; software needs typically evolve as you learn from users. Late discovery of misunderstood requirements; high cost of change; long feedback loops.
“What’s the V-model?” — Waterfall variant where each design phase pairs with a corresponding test phase, building traceability between requirements and acceptance tests. Common in regulated industries (automotive, aerospace, medical).
“What’s hybrid Waterfall/Agile?” — outer phased structure for contract / certification (formal phases, sign-offs); inner iterative development for actual implementation. Dominant pattern in enterprise / government Agile adoption.
“Did Royce invent Waterfall?” — described it in 1970 but argued against it; proposed iterative alternatives. The dogmatic Waterfall practice came from procurement, not from Royce’s recommendation.
“How would you respond to a customer demanding pure Waterfall?” — try to understand the underlying need (predictability, formal sign-offs, contract structure). Often the customer wants the outcomes of Waterfall (visibility, accountability) and can accept hybrid. If they truly need Waterfall (certification, fixed contract), deliver Waterfall.