spike
Spike
A spike is a standalone throwaway project that answers a question about the outside world. You keep the finding; you bin the code.
The question is always the same shape: is my assumption about some external thing true? Does this library support what I need. Does this API behave the way the docs imply. Can these two services actually talk. The only way to know is to make contact with reality - run the real thing in isolation and watch what it does.
This is the sibling of a prototype, split by what's uncertain. A prototype answers a question about your own logic, state model, or UI, and lives inside the host project so the good part lifts back out. A spike answers a question about someone else's code or service, lives in a scratch project of its own, and lifts nothing back - only the finding survives. If the uncertainty is your own design, that's a prototype, not a spike.
What makes it a spike
- Isolated from the host project. A fresh scratch directory with its own dependency manifest, never a folder inside the real source tree. Spike dependencies must never touch the real project's manifest - avoiding exactly that pollution is half the reason the spike is separate. Put it in a scratch dir (the session scratchpad,
/tmp, or aspikes/dir), well away from the code it informs. - Make contact with the real unknown. The whole point is reality, so the thing under question must be real: the real library, the real API endpoint, the real service. Stub the unknown and the spike proves nothing. Everything around it can be faked freely - hardcode inputs, paste a token inline, skip anything that isn't the question.
- Breadth, not depth. Trace the whole scope of the problem end to end - every stage the real thing has to pass through - but touch each stage as shallowly as it takes to move on. The failure a spike catches is "these pieces don't fit together", and you only see it by spanning the whole path, not by building any one piece well. A robust implementation of the first stage teaches you less than a flimsy pass through all of them.
- Shallow everywhere. No structure, no tests, no error handling, no retries, no config beyond what makes the real thing run. Happy path only - hardcode inputs, assume every call succeeds. Robustness is depth, and depth is what you are deliberately skipping.
- The finding is the deliverable, the code is disposable. What survives is written down: the answer, and the evidence for it. The project exists only to produce that.