Spike and Prototype
A time-boxed experiment run to reduce uncertainty about a specific question, producing evidence rather than a component.
When a decision hinges on an unknown — whether a technology performs adequately, whether an integration is feasible, whether an approach is workable — the cheapest way to decide is usually to find out rather than to analyse further.
What distinguishes a useful spike from exploratory drift: a specific question ("can this queue sustain 50,000 messages per second at our message size with our ordering requirement?"), a time box agreed in advance, a definition of what evidence would answer it, and the explicit understanding that the code is disposable. A spike that becomes production code by accident is the common failure, and it delivers the prototype's shortcuts into a permanent system.
Related techniques for the same problem: set-based design, carrying two options forward briefly rather than committing early, which is expensive and appropriate when the decision is one-way and the stakes are high. Reversible experiments in production behind flags, which produce the most reliable evidence of all. And staged commitment, where a pilot with one team or one customer precedes an estate-wide rollout.
The judgement is proportionate to reversibility: a two-way door does not warrant a spike — decide, and change it if wrong. A one-way door with a genuine unknown almost always does, and the spike is far cheaper than the meeting series it replaces.