Prototyping, incremental delivery, and the spiral

Prototyping is a requirements instrument

Prototyping earns its place in two situations. In the first, the customer can tell you the general objectives but cannot pin down the individual functions and features underneath them. In the second, the uncertainty is on your side of the table: you do not yet know whether an algorithm will be fast enough, whether the platform will bend the way you need it to, or what shape the interaction between the person and the machine ought to take. It runs as a loop: communication to agree the objectives and mark what is still undefined; a quick plan covering one short iteration; modelling in the form of a quick design, which is a sketch restricted to the parts a user will actually see and touch — screen layout, the shape of the output; construction of the prototype; then deployment, delivery and feedback — and round again, until the people asking and the people building have the same picture in their heads.

The important thing about that loop is what it produces. It does not produce the system. It produces better requirements. A prototype is judged by which question it settled, not by the quality of its code — which is why the interesting failure mode is political rather than technical.

Settle the terms before you start

Prototyping can be a stand-alone process model, but it is far more often a technique used inside another model, and saying so is worth a mark on its own. Whichever way it is applied, it fails in the same two ways. First, the people looking at it cannot tell a demonstration from a product. What they see behaves like software, so they assume the structure behind it is real — when in fact nobody has yet spent an hour on how it will be maintained, and nobody was meant to. Second, the shortcuts that made the thing run in a fortnight do not announce themselves later. The hard-coded token and the in-memory store are invisible from the outside, and unless somebody deliberately takes them out they simply become how the system works. The fake datastore you wrote on Friday is architecture by Monday.

The defence is procedural rather than technical: settle the terms before anyone writes a line. Everyone agrees, in writing, that this prototype exists to establish requirements, and everyone agrees which kind it is — throwaway or evolutionary. Sometimes the right call is to build it so that it can grow into the product; sometimes the honest call is to accept in advance that most of it will be thrown out once you know what the customer actually needs.

Evolutionary models and the spiral

Real systems grow while you are still building them. What the business needs in month nine is not what it asked for in month one, which on its own makes a straight line from start to finish a fiction; add a deadline that will not move and the choice becomes a limited version now against a complete version that never ships. Evolutionary process models are built for that: they apply the framework activities repeatedly, and each circuit hands you a fuller version — an increment — of the software.

The spiral model, proposed by Boehm, is the disciplined member of that family. It takes the looping shape of prototyping and bolts onto it the things waterfall is good at: defined stages, recorded decisions and a deliberate commitment point. The team travels clockwise from the centre outwards; each circuit passes through the framework activities and produces a release, which on the earliest laps may be no more than a model or a prototype and on later ones a progressively fuller system. Two things distinguish it. Every lap carries an explicit risk assessment, and the verdict of that assessment is what authorises the spending on the next lap. And every pass through the planning region rewrites the plan — cost, schedule and the number of laps still to come are revised against evidence rather than defended.

It is not a panacea. Customers, and contract customers especially, often do not believe that something which openly plans to revise its own plan is under control, and persuading them is real work. It also depends on genuine risk-assessment skill: a threat nobody spotted is not managed by having drawn a spiral around it.

Worked example — BorrowBox's first three months

Circuit 1 — throwaway. Two weeks. A clickable reserve-and-collect flow with a fake locker, taken to the depot car park and put in front of eight members wearing gardening gloves in direct sunlight. It settles one question and kills one idea: the four-digit PIN is unusable with gloves on, so the design moves to a scanned QR token. The code is deleted. The requirement it produced is not.

Circuit 2 — evolutionary. Six weeks. A real reservation service and a simulated locker controller, built to production standards because this one is meant to survive. The risk analysis at the start of the circuit names the real threat — the locker vendor's firmware SDK, whose last two releases slipped — and the circuit is planned around it: the simulator exists precisely so that the vendor is not on the critical path yet. The plan is revised at the end of the circuit; two features move out of increment 3.

Circuit 3 — evolutionary. Real hardware in one locker bank, with members using it; a no-go here is cheap and a no-go after the public launch is not.

Notice what the increments share: each is usable, each changed the plan, and the risk question was asked before the money was committed rather than after it was spent.