A design prototype needs a decision and a disposal rule

A prototype earns its place in technical design when it changes a decision. A large demonstration that everyone likes can still leave the difficult architecture question unanswered. Before writing exploratory code, name the uncertainty, the evidence that would resolve it and the condition under which the implementation will be discarded. Otherwise the first working version can acquire a production commitment nobody intended.

This November 2026 retrospective returns to Doug Turnbull's 14 December 2024 argument for throwaway code. He proposed draft pull requests that a team does not intend to merge, using implementation to discover a design. That is a practitioner's account and recommendation, not comparative evidence that coding always beats documentation. The useful question is when concrete execution can settle an uncertainty that prose leaves open.

Keep the decision smaller than the feature

Consider an illustrative reporting application whose engineers disagree about whether report generation should depend directly on database queries or receive a prepared data structure. The reversible decision is the boundary between data access and report rendering. The prototype does not need to deliver a complete reporting product. It needs enough representative input and one output path to reveal where that boundary helps or creates awkward dependencies.

Write the competing explanations before starting. The prepared structure may isolate rendering from storage changes. Direct queries may express filtering more clearly and avoid maintaining a second representation. Neither claim wins because its example is shorter. The investigation needs to expose the cost relevant to the disputed boundary, including where information is duplicated or where the renderer unexpectedly needs another query.

A draft PR can hold this comparison in a form engineers can inspect. Keep the question in its description and label the implementation disposable. Show which parts are representative and which are shortcuts. A fake data source may be appropriate for exploring the interface, but it cannot establish behavior under the real database's failure or transaction conditions.

Say what would change your mind

The reversal condition makes the decision reviewable. For the report example, the team might initially prefer a prepared structure, but reverse that choice if ordinary report variations repeatedly require storage-specific knowledge inside the renderer. This is a proposed decision rule, not a finding from a test performed here. The relevant evidence would be the actual variations and the dependency they expose.

Reviewers should be able to challenge the input selection as well as the code. If every example has identical filtering needs, the experiment may favour the proposed abstraction by construction. Include a case that could defeat the preferred design. A decision that survives a meaningful objection is more informative than a demonstration built exclusively around the easiest path.

Stop when the question is answered or when the experiment can no longer answer it cheaply. If realistic input is unavailable, record that limitation. Do not quietly fill the gap with invented traffic, expected savings or a claim that the team has validated production suitability. A bounded unanswered question is useful evidence for deciding what to investigate next.

Disposal belongs in the opening agreement

A practical disposal rule is to close the experimental PR after recording the decision, then implement any accepted design through separately reviewed changes. Preserve links to the experiment as historical evidence. The production work gets its own acceptance conditions, error handling and tests appropriate to the real behavior. This prevents a prototype's shortcuts from becoming invisible assumptions in a released system.

Closing the PR does not mean the knowledge disappears. Record which alternative was chosen, the observed reason and the condition that would justify revisiting it. A later engineer should be able to distinguish a deliberate tradeoff from an accidental constraint. The code demonstrates what was explored; the decision note explains which part of that exploration mattered.

The business consequence is scope control. A manager can authorize investigation of one boundary without implicitly authorizing an entire feature or its release. Engineers can return an answer that rules out work as readily as one that recommends it. The value lies in avoiding a poorly founded commitment, although this article assigns no monetary saving to that possibility.

A document can be the better first artifact

The strongest objection is cross-team coordination. People responsible for operations, contracts or customer support may not be able to assess a draft diff. They may also need to question the goal before anyone can choose a meaningful implementation. A short document can make the alternatives and constraints accessible earlier than code.

Turnbull's own article makes room for documents when gathering stakeholder feedback or when the organization cannot reliably discard first solutions. That last limit matters. A senior engineer's convincing demonstration can make disagreement harder for colleagues, especially if management treats running code as approval to ship. An explicit disposal label helps, but cannot repair a team that ignores it.

Use a document first when the uncertainty is about responsibility, requirements or coordination. Use a disposable implementation when the uncertainty concerns how concrete components fit together. Often the sensible sequence is a paragraph defining the question, a narrow experiment and a decision note that people outside the code review can read.

For custom software development, this is an engineering decision inside an agreed project. It differs from choosing a buyer-facing MVP or validating whether a product has a market. End the investigation with a choice, the evidence that could reverse it and a closed experiment. That gives the team a design it can revisit without inheriting the first implementation merely because it exists.