Technical Spike
Time-boxed exploration to reduce risk before committing to a full build. Learning, not building.
A technical spike is a fixed-block of time : usually one to two days : dedicated to answering one specific question: “Can we actually do this?” You’re not building the feature; you’re buying information. The output isn’t code, it’s a verdict: yes, no, or “yes, but with these constraints.” Three rules make it work: fixed time box (stop when it goes off, regardless of where you are), one question (write it before touching a keyboard), and throwaway code (its job is to produce knowledge, not production artifacts).
How It Works
State the exact question → set a hard deadline → explore with the intent to discard → deliver a verdict. If the spike succeeds, rebuild properly. If it fails, redirect before burning weeks on a dead end.
Example
The oil model’s v14 AR error correction spike asked one question: “Can an autoregressive model correct its own prediction errors in real-time without blowing up latency?” A focused two-day spike answered yes, which reshaped the entire v14 architecture. Without it, the latency constraint would have been discovered after weeks of wasted engineering. Detailed in v14 AR Spike.