spike

Spike

A spike is not a small implementation. It is an experiment that buys information, and the code is the apparatus, not the product. The value ships in the findings; the code gets deleted.

Holding that distinction is the whole skill. The failure mode is not writing bad spike code — bad spike code is correct. The failure mode is drifting: starting with a question, getting something working, and quietly sliding into building the feature. That produces shortcut-quality code that nobody dares delete and nobody wants to own.

The contract

1. A spike answers questions. If you cannot state what you'd learn, it isn't a spike.
2. The code is disposable and is actually disposed of. Torn down when the findings are written.
3. Nothing from the spike is promoted. The real implementation is written fresh, informed by what was learned. Copying spike code forward smuggles the shortcuts into production.
4. A null result is a result. "This approach can't work because X" is a successful spike, often the most valuable kind. Never twist a spike toward a positive answer.

Step 1 — Name the unknowns before writing anything

Turn the vague ask ("let's spike the new sync layer") into a short numbered list of questions that could come back no. Then state them and start. Don't wait for approval — but do state them, because if you picked the wrong questions the user can redirect you in one sentence, and that's far cheaper than finding out at the end.

A real spike question is falsifiable and decision-changing. Apply both tests:

• Falsifiable — there's an observation that would settle it. "Is the architecture good?" fails. "Does the batch endpoint return partial failures per-item or fail the whole batch?" passes.
• Decision-changing — write down what you'd do differently for each answer. If both answers lead to the same plan, drop the question; you're about to spend effort on something you already know how to handle.

Common shapes worth reaching for: