Iterative Development

Getting it right in one pass was the default assumption for a long time. Write down everything to be built, design it, build it, and test it at the end. That order, known as waterfall, looked easy to manage because each stage closed before the next one opened.

The trouble sat in the first stage. It assumes the team knows what to build before building it, and some things simply aren't knowable until a screen exists. How many search results to show at once, whether filters belong above the list or beside it — those can be written into a document and approved, but whether the choice was right only becomes visible in use.

So the meeting after development always took the same shape. Someone seeing the finished screen for the first time after six months says this isn't what they meant, and the team that built it says it matches the document that was signed off. Both statements are true. The person simply learned from the screen what the document couldn't tell them, and fixing it now means unwinding six months.

Iterative development drops that assumption. Starting without full knowledge is treated as normal, and in exchange the process creates repeated chances to act on what gets learned. Look at the work every two weeks instead of every six months and "this isn't what I meant" costs two weeks of rework.

Each cycle runs planning, design, build, and review end to end, and the next cycle returns to the same thing with what the last one revealed. Rather than passing through each stage once, the work goes around a small loop several times.

Building a search screen tends to go like this.

1. Cycle one gets as far as typing a query and seeing results. No sorting, no filters, and a rough screen, but search actually works.
2. The team uses it, internally or with a slice of users. Things invisible on paper show up here: results come back 20 at a time and the useful one is always near the bottom, or people type two or three words rather than one.
3. Cycle two reopens the same screen with those observations in hand. Recent documents get sorted to the top, and multi-word queries get handled properly.
4. Cycle three comes back to it once more, this time to deal with results taking three seconds to appear.

Returning to one screen three times is the signature of the approach. Reopening finished work looks wasteful, but splitting the work across three passes is exactly why the sorting rule in cycle two rests on observed usage rather than on a guess.

Two conditions make this work. Cycles have to be short: if one loop takes six months, there are two chances a year to correct course and nothing separates it from waterfall. And something that actually runs has to exist at the end of each cycle, because a finished design alone produces none of the observations that step 3 depends on.

Teams working in fixed sprints have this built into their calendar. Committing to an output every two weeks fixes the length of one loop, and the retrospective at the end of the cycle puts the working process itself on the same repeating schedule as the product.

Launching a product follows the same shape. An MVP is the smallest version that can test an assumption, and it isn't an endpoint — it's the starting position for the next version. Learning that people click somewhere unexpected in the first release becomes the input for the one after it.

Design runs on the same loop at different resolutions. A wireframe settles layout and gets reviewed, a prototype makes the flow clickable and gets reviewed again, and the built screen gets reviewed once more. Three passes over one screen, with the question narrowing each time: does the layout read, does the flow hold together, does it survive real data.

"Let's just make it work this cycle and add sorting next time."

A proposal to complete one loop first and defer polish.

"Ship the first version, watch what happens, and refine in the second."

There isn't enough evidence to decide now, so usage becomes the evidence.

"We're reopening the same screen this cycle with what we saw last time."

Revisiting finished work is the plan, not a setback.

Pagedeck's document search was built this way. What Mia put into the first cycle was a single-keyword search over titles only. The screen Noa designed had an input and a list and nothing else, and Theo argued for leaving full-text search out — tuning relevance takes time, and whether it was needed at all came first.

Two weeks of usage showed people typing sentences from inside documents because they couldn't remember titles. Full-text search went into cycle two, and cycle three added narrowing by author and date range after people reported getting too many results to scan. All three cycles opened the same screen, and each time the previous cycle's observations decided what went in.

The most common reading is that building the same thing repeatedly is waste — doing three times what one careful pass could have done once. Rework does cost something, and that's real. But the comparison isn't against getting it right the first time; it's against finding out six months later that it was wrong. Changing the sorting rule in cycle two takes three days. Changing it after everything is built takes three weeks, because by then the sorting rule has other work stacked on top of it.

Mistaking it for working without a plan is the other one, since "iterate" sounds close to "improvise." In practice each cycle has a question it intends to answer, and the answer is the next cycle's input. Iteration without a question just circles the same spot, and three cycles later nobody can explain why the screen looks the way it does.

Using it interchangeably with incremental development is common too. Both split work into short repeated releases, so they blur together. The direction of the split differs. Iterative development goes over the same thing repeatedly and sharpens it; incremental development finishes one piece at a time and attaches it. Building a rough search screen and refining it three times is the first. Finishing search, shipping it, then attaching a whole filter screen is the second. Real teams mix them, so the useful question is which of the two a given cycle leans on rather than which label the team claims.