Evolutionary Prototyping

Goal

Evolutionary prototyping exists to deliver a working solution while its requirements are still being discovered. The elicitation instrument is the real use of a real increment: a first usable version goes into service, what stakeholders do with it is observed, and what they do with it decides the next version. BABOK describes the mechanism in one descriptive sentence: prototypes are created to extend initial requirements into a functional solution, as requirements are further defined through stakeholder use.

The deliverable is the solution itself: the increment is the product, and that is why it must be of production quality. BABOK adds one reservation worth keeping as it stands: the prototype may be used in the final solution. The guide describes a practice, and it states no obligation of architecture, quality or security. Those obligations exist, they are heavy and they rest elsewhere.

Because nothing is thrown away, there is no later moment at which shortcuts get made good, and the quality floor, architecture, security, data protection, tests, operability, is paid from increment zero. The decision the technique supports is this one: what should we build next? It supports it with evidence of use. That is a real gain, and it has to be named to see what it costs: what people do with an increment that is in service is a requirement; what they say about it in a workshop is an opinion about a requirement.

Usage

When to use it

• Interface design and design systems: the artefact is a production asset from the first stroke.
• The production floor already exists: architecture, authentication, logging, tests and the delivery pipeline are in place.
• Requirements cannot be stated in advance: only the use of a genuinely usable increment reveals them.
• Stable domain, small solution: use is unlikely to invalidate the architecture the first increment fixes.
• The sponsor funds a production release from the first increment: that is the technique's real price.
• The delivery pipeline is already continuous: without it, the loop of use does not turn.

When not to use it

• The question on the table is « what should we build? »: throw-away prototyping answers it for a fraction of the cost.
• The production floor cannot be funded at the first increment: learn on a throw-away prototype, then build the solution properly.
• Personal or sensitive data, no threat model yet: settle the threat model and the architecture first, explore the interface with a throw-away prototype.

Description

Two independent axes

BABOK classifies prototypes on two elements, and confusing them is expensive. The approach says what becomes of the artefact: you throw it away, or you grow it into the solution. The method says what it is made of and what someone does with it: a storyboard that is read, a paper prototype that is operated, a simulation that a machine executes or workflow modelling, a borrowed method whose home is process modelling. Every prototype carries an answer on each of the two axes, and the two answers are free of each other. Evolutionary prototyping is an answer on the approach axis: it fixes the fate of the artefact and says nothing about the medium. It is prototyping taken as a whole that governs the routing between the two axes, and the only comparison that means anything is one that stays on the approach axis: keep the artefact or throw it away.

The artefact becomes the solution

The mechanism runs in four beats that repeat. An increment is built, it goes into service with real users doing real work, the use is observed and what is learned from it decides the next increment, built on the same codebase. The words carrying all the weight are into service: a demonstration in a room, a sandbox, an acceptance environment full of invented data do not close the loop, because they produce no use. They produce comments, and you then have the cost of the evolutionary approach without its benefit.

There is no discard event, so there is no cleanup event either. No date on the calendar reads « throw the prototype away and write the real version ». What increment zero left out stays in the product, in production, for the lifetime of the system. The quality floor is therefore paid in full before the first question has had its answer. That is the technique's real bill.

Running evolutionary prototyping

1. Decide the approach before the first line
   The choice between keeping the artefact and throwing it away is made once, and it does not come undone cheaply: from the second increment onward, throwing it away means throwing away software that is in service. Write the decision, write its reason and write what would force it to be reversed.
2. Write the reversal trigger in advance
   It is the kind of signal that gets recognised too late. Two are worth putting down in black and white: what the use of an increment teaches invalidates the architecture that increment zero fixed, or the next increment cannot lawfully be placed in the hands of real users under the cantonal data-protection regime. Once either is hit, the next step is not to patch the increment. It is to freeze the series, to treat what is running as a throw-away prototype and draw the lesson from it and to rebuild the floor on the architecture that use has finally identified. The cost of that reversal grows with every increment, which is why its threshold is written before the first one.
3. Pay the floor and call it increment zero
   Authentication and authorisation, logging and an audit trail, encryption, the legal basis for processing the data, error handling, an automated test suite, a delivery pipeline, monitoring, backup and restore. If that list looks out of proportion to the question you are trying to settle, the feeling is correct, and it is the signal that what you need is a throw-away prototype.
4. Define the smallest increment that can genuinely be used
   By real people doing real work, with real data. The criterion is the capacity to produce use: one use case handled end to end beats five screens half wired up.
5. Release it and get it used
   The elicitation instrument is real use, exercised by the people whose job it is, under the conditions in which they do it.
6. Observe what people do with the increment
   Telemetry, drop-off points, support tickets, questions asked at the counter, workarounds people invent. A workaround is a requirement that was not met, the richest datum the technique produces.
7. Settle the next increment on that basis, with the stakeholders and write down what use has settled
   That last clause is the one teams skip, and its absence is what separates evolutionary prototyping from a plain sequence of releases. Without it, the technique produces a system and no requirements: the code encodes the decision and nobody can state it.
8. Hold the floor at every increment
   No increment goes below it. The day one does, the debt contracted has no repayment date, because the calendar provides for none.
9. Recognise the moment the word « prototype » stops doing any work
   If every increment is of production quality and every increment is delivered, the team is doing incremental delivery, and it is better to say so and drop the word.

There are three deliverables. There is the solution, increment by increment, since the artefact is the product. There is the record, per increment, of what use has settled, which is the only requirements trace the technique leaves behind. And there are the architecture and security decisions of increment zero, which are the floor everything else rests on and which nobody will reopen. HERMES 2022, the method the Swiss administration follows, treats the prototype and its documentation as two distinct results of the prototyping task, separate from the results of the product itself.

The quality floor cannot be retrofitted

Security is where this property stops being an engineer's preference and becomes a constraint of nature. OWASP puts it in the plainest terms, on the subject of design flaws: « A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. » An implementation defect is fixed by a patch. An insecure design is fixed by a design, which is to say by a rewrite, which is to say by the discard event this approach has removed.

CISA and its international partners say the same thing from the manufacturer's side: security is built into the product from its design and development, and it is the supplier, not the customer, who owns the outcome. But a prototype omits security by definition, and that omission is part of what makes it fast. Keeping the prototype means keeping the omission. Building security on top of an artefact that was designed without it is a programmed failure, in the literal sense: the calendar contains no slot in which that catching-up could take place.

In Switzerland the requirement is legal as well. Data protection by design, the principle set out in art. 7 of the Federal Act on Data Protection and taken up by the cantonal data-protection acts that govern cantonal and communal public bodies, requires technical and organisational measures from the design of the processing onward, together with default settings that limit the processing to the minimum. An increment zero that processes personal data and defers data protection is in breach before it is online.

Boehm's spiral

The correct theory of the prototype as an instrument was written in 1988 by Barry Boehm, and it is the exact opposite of the evolutionary approach. The spiral model is risk-driven: each cycle identifies objectives and options, identifies and resolves risks, the prototype being the instrument of choice for that, and commits to the next level of elaboration only once the risk has been bought down. The prototype there buys a reduction in uncertainty before commitment.

Evolutionary prototyping commits first. Increment zero is the product, and the architecture it fixes is decided at the moment the team knows the least it will ever know. These are two opposite stances towards the same instrument, and it is by naming the spiral that you see them.

Twelve years after the founding article, Boehm had to publish a report at the Software Engineering Institute setting out six invariants of any spiral development, with the explicit purpose of excluding the hazardous spiral look-alikes, the false resemblances that had taken the name. The models it excludes are exactly what teams were doing under that label: a sequence of incremental waterfalls where the waterfall's assumptions do not hold, cycles that exclude essential stakeholders, incremental processes with no architectural planning at all, approaches fixated on developing the initial code. The report documents the gap: under the name of the spiral, teams were doing something else. That such a report was needed twelve years after the article is the measure of the gap. And the commonest of those look-alikes, a sequence of incremental waterfalls with no risk analysis, is the shape a badly run evolutionary prototype takes.

Savings and costs of the approach

A prototype exists to learn. The question it settles is « what should we build? », and that is the expensive question. Brooks established it in No Silver Bullet, and the sentence has not aged: « The hardest single part of building a software system is deciding precisely what to build. » No other part of the conceptual work is as difficult, none cripples the resulting system as much if it is done wrong and none is harder to rectify later. The rest, writing the code, is what Brooks files under the accidental.

The cost evolutionary prototyping claims to avoid is the cost of rewriting code. That is the cheaper of the two, and it is paid after the learning has happened. The cost it charges, the production floor, is the heavier one, and it is collected before. So the approach saves the wrong cost, and it does so at the least favourable moment. In software this is not the default choice, and it should not be.

Brooks went further, and his conclusion is regularly conscripted into the wrong camp. In the anniversary edition of the Mythical Man-Month he withdraws his 1975 advice (build a first system knowing you will throw it away): « This I now perceive to be wrong, not because it is too radical, but because it is too simplistic. » What he embraces instead is incremental growth. But what he grows is the product: his system starts from a skeleton of the real system, which runs and still calls nothing but empty subprograms and is then fleshed out piece by piece. Every stage is the product. He never wrote that one should keep a mock-up and extend it, and he does not settle the debate between the two approaches: he establishes that the choice is real and that it has consequences.

The discipline that describes what Brooks recommends carries another name. Beck calls it incremental design: design is done in the light of experience, it is deferred to the last responsible moment and every increment is of production quality and delivered. It is the primary source of the practice sometimes described as the heart of agile development.

The conclusion fits in one statement: the discipline that makes evolutionary prototyping work is the discipline that makes it stop being a prototype. Build increment zero to production standard, hold the floor at every increment, write down what use has settled: at that point the team is doing incremental delivery, and the word prototype is doing no work at all in the sentence. Miss it, and you are growing a demo into a production system. The same distinction shows in the structure of HERMES 2022: the prototype produced and its documentation are results there, the developed product is another and the method lets the product be built in a classic or an agile manner, without needing to be called a prototype in order to be delivered in stages.

The exception: design

There is one domain where the approach pays honestly. In an interface design tool such as Figma and its kin, the artefact is a production asset from the first stroke. The design system is a set of standards maintained like living code and consumed by the delivered product, as the Nielsen Norman Group describes it. Design tokens are variables that the design tool and the codebase both read. The CSS carries across as it stands and the HTML to a degree.

The reason is structural: beneath a design artefact there is no runtime, no persisted data and no attack surface. So there is no quality floor to catch up on. Nothing in a Figma component can be exploited, corrupt a record or reveal a resident's address. The exception stops exactly where the artefact acquires an execution engine and a database: the screen mock-up survives into the product, the behaviour it promises remains entirely to be built and it is that behaviour which carries the floor.

What makes evolutionary prototyping fail

The demo that becomes the system

BABOK names the mechanism: when the prototype is highly elaborate and detailed, stakeholders develop unrealistic expectations of the final solution, including its completion dates, its performance and its reliability. An increment that looks finished is treated as finished, by the sponsor and by the team.

Technical debt with no repayment date

Cunningham's metaphor is precise, and it is regularly quoted backwards: shipping first-time code is going into debt, and a small debt speeds development so long as it is repaid promptly with a rewrite. The debt he described is an immature understanding of the domain, shipped in code, which is exactly what an early increment is. An approach whose premise is that the code is never rewritten has removed the repayment from the loan.

Migrating real data, at every increment

The artefact is in service, so there is no moment at which you drop the database and start again. Every schema change from v1 onward is a migration executed against the records of real people, with its rollout, its reversibility and its trace, under the data-protection floor. That work appears in no prototype estimate, and it grows with every increment.

The architecture frozen by increment zero

The first increment is written under the weakest knowledge of the problem the team will ever have, and it becomes the floor for everything else. It mirrors the previous trap, and it is what makes the approach viable on a stable, small domain and punishing on an exploratory one.

The criticism dries up

BABOK observes that with a mock-up users feel freer to be critical because it is not polished and release-ready. An increment in production is release-ready, indeed already released: stakeholders then criticise it as a product, cautiously.

The « how » drives out the « what »

The first limitation of prototyping according to BABOK, and this approach is the most exposed to it: the artefact is real code, so the room talks about implementation when it should be talking about need.

The requirements are written nowhere

Use settled the matter, and nobody wrote down what it settled. Three years later a rule is in the code and its reason is nowhere.

The specialised tool becomes the ceiling

Low-code platforms make increment zero fast and the floor invisible: authentication, data residency, audit trail, exit cost. The speed is real, and it is paid for out of the floor.

AI considerations

One observation commands the others, and it is specific to this technique: AI makes its failure mode more likely. It has never been cheaper to produce something that looks like a working solution: a plausible increment, with credible screens and a path that runs, with no threat model, no tenable data model, no error handling and no operability. The distance between a demo and a production system has not shrunk; the distance between the look of a demo and the look of a production system has collapsed. The decision « does this increment go into production? » remains human and carries liability.

Where the tooling renders a considerable service, it renders it on the floor. Generating a complete increment zero, an application skeleton with authentication, authorisation, logging, error handling, a test suite and an integration pipeline, costs today a fraction of what it used to: the bill this technique refuses to pay has come down, and that is the only thing that can change its economics. Reviewing each increment against OWASP's insecure-design categories, sketching a threat model before release, aggregating the support tickets, drop-off points and telemetry of a delivered increment into candidate requirements for the next, drafting the record of what use has settled, writing the migration scripts every increment demands because it runs on real data: all of that delegates usefully.

Two limits and the second is a guillotine. The first is that AI makes the sponsor's argument stronger: if writing code costs even less than before, then keeping a prototype's code to avoid rewriting it buys even less than before, while the expensive part, deciding what to build, stays exactly where it was. The second is that the increments run on real data, real people's data, from increment zero. No extract of the residents' register goes into a model operated by a third party, and the data-protection floor binds the tooling exactly as it binds the product.

Examples

A commune opens an online counter for its residents' registration office. Increment zero is the service in production: it is open to the residents of one pilot commune, it issues real certificates of residence from the real register, and it does so from the first day.

Increment zero cost more than the three that followed it put together. The authentication and the audit trail written for it are the ones still running in production several years later: they survived because they were written to production standard on the first day, on an artefact nobody ever planned to throw away.

The commune had to pay that floor in any case. The processing concerns personal data, and data protection by design applies to the file before the first line of code. So v0's bill was owed, and that is what makes the approach defensible in this case.

The system encodes the decision on representing a third party. It does not state it, and nobody will recover it by reading the code. The record of what use settled is the only place where that decision exists as a requirement: without it, the technique would have delivered an online counter and nothing else.

Visualisations

What to look for in the chain of increments is an absence: nowhere is there a bin, nowhere a cleanup step and no date on which anyone goes back over anything. That absence is the technique itself. The increment record carries the other half of the same fact: what use settled at each stage and what the floor cost once and for all.

The same chain, laid alongside a real project, serves as an audit instrument, and three checks can be read off it. Does the floor band really start at increment zero, or does it start somewhere in the middle of the chain? Does every increment genuinely pass through use or only through a demonstration? And is there anywhere in the plan a date on which someone goes back over things? If the answer to the last question is « we will clean it up later », the answer is an intention, and the technique provides no moment in which to carry it out.

Cost

Tooling

The exception has tooling of its own, and it is the only case in which the word prototype and the word production designate the same thing without reservation. Figma and its kin, with their component libraries, design tokens and a living component catalogue such as Storybook, produce an artefact the delivered product consumes directly. The design system is maintained like code, and it is versioned like code.

For software, BABOK notes that the approach usually requires a specialised prototyping tool or language, which today means the low-code and rapid-development platforms (OutSystems, Mendix, Power Apps, Retool). They keep their promise: increment zero comes out fast. They also make the floor invisible: authentication, data residency, the audit trail and the cost of leaving the platform are architecture decisions, taken by default by the tool, often without anyone having seen them go by. Choosing such a platform is handled as an architecture choice.

The tooling that genuinely carries the technique is the delivery pipeline: continuous integration and delivery, an automated test suite, feature flags, environments, monitoring and rollback. It is also the fastest diagnostic there is: when the tooling a prototyping technique requires is a full delivery pipeline, what the team is doing is delivery.

That leaves observation of use, without which the step that defines the requirements has no material: application telemetry, user-path logging, drop-off points, support tickets, feedback from the counter. In the Swiss public sector all of it is exercised under the cantonal data-protection regime, with compliant hosting and authentication from increment zero, which is an architecture constraint before it is a tooling constraint.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: the evolutionary or functional approach, requirements further defined through stakeholder use, the specialised tool and the limitations (unrealistic expectations, getting bogged down in the « how »).
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, ch. 19, Addison-Wesley, 1995: the retraction of the 1975 advice and the incremental growth of the product.
• Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer 20(4), 1987: deciding precisely what to build is the hardest single part and the distinction between essential and accidental difficulty.
• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988, pp. 61-72: the prototype as an instrument of risk reduction, resolved before commitment.
• Barry Boehm (Wilfred J. Hansen, ed.), Spiral Development: Experience, Principles, and Refinements, Special Report CMU/SEI-2000-SR-008, Software Engineering Institute, 2000: the six invariants and the hazardous spiral look-alikes they exclude.
• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley, 2004: incremental design, design done in the light of experience and the increment delivered at production quality.
• OWASP, Top 10:2021, A04 Insecure Design: an insecure design cannot be fixed by a perfect implementation.
• CISA and international partners, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software: security built in from design and development and the supplier's responsibility.
• Ward Cunningham, The WyCash Portfolio Management System, OOPSLA '92: the technical-debt metaphor in its author's own terms and repayment through rewriting.
• Swiss Confederation, Federal Act on Data Protection (FADP), SR 235.1, art. 7: data protection by design and by default, a principle taken up by the cantonal data-protection acts.
• HERMES 2022, task Carry out prototyping: the prototype produced and the prototype documentation as distinct results, separate from the product's results.
• Nielsen Norman Group, Design Systems 101: the design system as a set of standards maintained and consumed by the delivered product.