Waterfall

When large systems were built over the course of several years, finishing them in sequence was simply how it was done. The idea comes from construction. The drawings get finalized before the ground is broken, and the frame goes up before interior work starts. Reverse the order and a wall has to come down and go back up again, so settling each stage firmly ends up being the cheaper path.

The place this premise wobbles in software is requirements. People cannot say everything they want at the start of anything. Only after pressing the buttons on a finished screen do they discover that what they wanted wasn't quite that.

Pagedeck met that gap while building a feature for a public-sector delivery this way. Forty pages of requirements were finalized over two months, and four more months went into building it. Twelve findings came back from the acceptance review, and nine of them were the same in character: what had been built matched the document and didn't match the actual workflow. The person who wrote the document hadn't known that workflow precisely either, and only learned it once the screens actually existed.

Under agile, the approach of not fixing a plan once and for all but correcting direction across short repetitions, waterfall holds the seat of the contrasting concept. It's the seat that shows what agile came along to replace, and it has to be read as a question of conditions rather than one of right and wrong.

There are five stages, and each one ends in a deliverable that has to be approved before the next one starts.

1. Requirements analysis. Write down everything that is to be built. This document later becomes the basis for acceptance and for the contract, so whatever isn't written doesn't get built and whatever is written has to be.
2. Design. Fix the screen composition and the data structures in place. The deliverable here is what the schedule and headcount calculations are based on.
3. Implementation. Build what was designed. This takes roughly half of the total duration, and while it runs almost nothing visible from the outside comes out of it.
4. Testing. Check what was built against the document from step 1, line by line. Passing means that every item written there actually works.
5. Acceptance and operation. The customer reviews it, and once it passes, the work is handed over and only fixes remain after that.

The character of this process is that the cost of going back inflates at every stage. Changing one line during requirements means editing a document and nothing else. Changing the same line during testing means editing the design, the code and the test items, and anything already built that leans on that line has to be touched as well. That's why so much time goes into the early stages. Spending two months on requirements isn't waste; inside this structure it's the cheapest available option.

There are places where this method clearly fits.

1. Work whose requirements are set externally and don't change. Producing a regulatory report in a mandated format is one. Discovering a better format mid-build changes nothing at all, so there's no reason to go back and check repeatedly.
2. Work where the contract is tied to deliverables. When acceptance criteria are a document and payment arrives per stage, there's no way to settle accounts without dividing stages.
3. Work where the cost of reversal is extreme. Software going into equipment that can't be recalled once it has shipped belongs here.

The limits come out of that same place.

1. It doesn't fit work you have to learn by building. A new product where nobody yet knows which parts users will use is the obvious example.
2. Something that works arrives at the very end. Until then there is no way at all to confirm the direction was wrong, and by the time you can confirm it, fixing costs the most it ever will. Iterative development, circling the same subject to raise its quality, came out aimed at exactly this gap.
3. The document and reality drift apart. When judgments changed during implementation don't get reflected back, step 4 is comparing against an outdated document.
4. Real teams usually mix the two. Keeping the contract and the stage divisions as waterfall while running short repetitions inside is common: fill the inside with incremental development, adding usable pieces one at a time, and produce stage deliverables for the outside.

"Requirements here are set by law, so waterfall is the right call."

Choosing the method from the conditions rather than from preference.

"The contract is stage-based and we run two-week cycles internally."

Separating the process facing outward from the process running inside.

"Changing requirements now edits a document. Changing them in testing is two months."

Pointing out that the cost of going back differs enormously by stage.

At Pagedeck this method is used only for public-sector and large-enterprise deliveries. Grace looks at the contract structure and decides the method, and Mia writes the requirements document together with the client's owner. During the two months spent on those forty pages, half of what Mia does isn't writing but drawing paper screens to show that owner. The first delivery taught the team that a document on its own doesn't let somebody write down their own workflow accurately.

The most common position is that waterfall is outdated and agile is correct, since whatever arrived later naturally reads as better. But the two address different conditions. Where the subject doesn't change and there's no reason to go back, finishing in sequence wastes less, because running repetition cycles costs something of its own. The test isn't new versus old but one question: is this work you can know the shape of without building it first.

The other frequent belief is that writing a lot of documentation makes it waterfall, because the line about reducing documentation gets quoted often from the agile side. But the sentence in the Agile Manifesto doesn't say don't write documents; it says that when documentation and working software conflict, choose the latter. What actually separates the two methods is whether stages can be revisited at all, not how much documentation exists. A team that writes forty pages of requirements and revises that document every two weeks isn't doing waterfall, and a team with no documents at all that finishes in sequence and never goes back is.