In the late 1990s a supermarket chain decided to replace the ageing software that scheduled every delivery lorry in the country. A team spent two years writing it, phase by phase, to a specification agreed at the very start. When it finally went live it scheduled trucks to drive to depots that had since closed, for products the chain no longer sold. The code did exactly what the two-year-old document asked — and the business had moved on underneath it. The system was scrapped.
That is the central drama of building software: it is rarely a single act of typing. A real system is born, grown, corrected and eventually retired, and the world keeps changing the whole time. The software development lifecycle (SDLC) is the name we give to that journey — the ordered set of phases a piece of software passes through from first idea to final switch-off, and the different models teams use to move through them. Getting the model right is often the difference between the delivery-lorry disaster above and software that actually helps people.
Whatever process a team follows, roughly the same kinds of work must be done. Naming these phases is
just
The interesting question is not what the phases are — everyone roughly agrees on those — but in what order and how many times you go through them. That choice is the software process model.
The oldest and simplest model is the waterfall. You do the phases strictly in sequence: finish all the requirements, then do all the design, then write all the code, then test, then deploy. Like water going over a series of ledges, work only ever flows downward — each phase is signed off and completed before the next one starts, and you do not expect to go back up.
Its appeal is real. Everything is planned up front, so you can estimate cost and time early, write a fixed contract, and hand clean documents from one specialist team to the next. For a project whose requirements genuinely cannot change — a bridge's control system, a pacemaker, something governed by a fixed legal standard — the discipline of waterfall is a strength.
The picture is usually traced to a 1970 paper by Winston Royce. The twist of history is that Royce drew the strict top-to-bottom diagram in order to criticise it: he argued that a single downward pass is "risky and invites failure", and that you must loop back between phases. Later readers kept his tidy diagram and quietly dropped his warning — and so the model became famous under a name meaning almost the opposite of what its author intended. It is a lovely reminder to read past the first diagram.
The fatal assumption of waterfall is that you can know everything you need up front and that it will stay true. In practice neither holds. Users often cannot tell you what they want until they see something; markets, laws and competitors move; and mistakes made in the requirements phase stay hidden until testing — potentially months later — by which time they are enormously expensive to fix.
Worst of all, a working program does not exist until almost the very end. In our delivery-lorry story, nobody could use the software — and therefore nobody could notice it was solving the wrong problem — until two years of budget had already been spent. Waterfall concentrates all of a project's risk into one enormous, late, all-or-nothing reveal.
The iterative family of models answers waterfall's weakness with a simple change of shape: instead of one long march through the phases, you go round them many times in short cycles. Each loop — a plan, a bit of design, some code, some testing, a review — is small (days or a couple of weeks) and ends in a working increment: a slice of the real product you can show, use, and get feedback on.
Agile is the best-known modern take on this idea. Its watchword is to embrace change: rather than fighting to freeze requirements, you assume they will evolve and organise the work so that changing your mind next week is cheap and normal. Because a usable version exists after the first loop, the team learns what users truly need early — and steers, loop by loop, toward the right thing instead of discovering at the end that they built the wrong one.
This is what people mean when they say iterative development de-risks a project. Each cycle is a small, cheap bet. If a loop reveals a bad assumption, you have lost a fortnight, not two years — and you correct course on the very next loop.
A classic misconception is that agile means "no planning" and "no documentation" — just start coding and see what happens. That is not agile; that is chaos, and it fails just as badly as an over-planned waterfall. Agile teams plan constantly — they simply plan in short, frequent bursts (what to build this loop) rather than in one giant document up front, and they revise the plan as they learn. Likewise they write documentation, just enough and when it is useful, favouring "working software over comprehensive documentation" rather than "no documentation". The shift is from predicting everything early to adapting continuously — not from discipline to none.
Suppose your student society wants an app to show what is happening on campus this week. Watch the same job play out under each model.
Waterfall: You spend three weeks interviewing everyone and writing a 40-page spec for every feature anyone mentioned — maps, ticketing, notifications, photo galleries. Then a month of design, two months of coding, a fortnight of testing. On launch day you discover students only ever wanted a simple list of today's events with a location; the ticketing system nobody uses took half your effort, and the one feature people beg for — a reminder — was never in the spec.
Iterative / agile: Loop one (one week): plan the single most valuable slice — a list of today's events — design it lightly, build it, test it, and show it at the society meeting. People love the list but immediately ask for reminders. Loop two: add reminders. Loop three: a friend points out the list is useless off-campus, so you add offline caching. After a month you have a small app people actually use, and every feature earned its place by surviving contact with real users.
Same phases, same team, same effort — but the iterative version steered toward what was wanted, while the waterfall version faithfully delivered a two-month-old guess. This is why most modern product teams work iteratively, reserving strict waterfall for the rare cases where the requirements genuinely are fixed and known in advance.