Spike
Description
A time-boxed investigative task whose purpose is to reduce uncertainty before committing to a build. The output is understanding (cost estimate, feasibility verdict, structural sketch), not shipped product; the cost is bounded by the box, not by the scope of what’s being investigated. Distinguishes from “research” (open-ended, no fixed scope-or-time) and from “prototype” (intended-to-become-real after iteration). The spike’s defining move is the commit/no-commit decision at the end of the box: after the timebox expires, the project either commits to a full build informed by the spike’s findings, or kills the direction. The code produced during the spike is throw-away; the understanding is retained. Composes with cost-cascade (cheap investigation before expensive commitment; the spike IS the cheap stage gating the expensive stage), grain (the spike’s grain — depth of investigation — is itself a choice with cost implications), load-bearing (the spike should target the load-bearing uncertainty, not the salient-but-incidental one).Exclusions
The diagnostic question — what commit/no-commit decision does this box exist to inform? — category-mismatches in four distinct situations:- Prototype intended to become production. When the code or artifact built during the activity is meant to survive into the shipped system after iteration, the activity is a prototype or MVP, not a spike. The throwaway-output property is structurally load-bearing: a spike’s value comes from being unencumbered by code-survives-the-investigation constraints. Aerospace formalizes this distinction explicitly — an X-plane is a research vehicle; a prototype is a pre-production aircraft; treating them interchangeably destroys the structural advantage.
- Open-ended research without a scheduled commit decision. Investigation that has no fixed terminus and no go/no-go gate at the end is research, not a spike. The box-then-decide shape is what distinguishes the two. Research optimizes for understanding-as-end; a spike optimizes for understanding-as-input-to-a-specific-pending-commitment. Without the pending commitment, the time-box has nothing to be sized against.
- Production debugging or incident response. Diagnostic work driven by an existing failure has a known target (restore service, identify the regressing change) rather than a commit-or-kill decision about a future investment. Sharing the time-pressure surface with a spike doesn’t make it one — the shape of the decision at the terminus is different (it’s resume-prior-state, not commit-new-direction).
- Salient-but-incidental investigation. A time-boxed activity that targets a visible-but-non-load-bearing uncertainty wastes its box and returns understanding the build never needed. The discipline a spike requires is upstream: identifying which uncertainty, resolved negatively, kills the program at lowest cost (per the Phase 1 clinical trial example — safety before efficacy because toxicity kills the program cheaper than ineffectiveness does). If the box targets the wrong uncertainty, even a well-executed spike fails its purpose.
Structure
Relationships
Examples
Kent Beck, "Extreme Programming Explained: Embrace Change" (2nd ed., Addison-Wesley, 2004), Chapter 7 (Primary Practices) and Chapter 12 (Planning). Companion definition in William Wake, "Extreme Programming Explored" (Addison-Wesley, 2000), Story Estimation chapter: "We call such an experiment a 'spike solution', to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out." · computer-science
Kent Beck, "Extreme Programming Explained: Embrace Change" (2nd ed., Addison-Wesley, 2004), Chapter 7 (Primary Practices) and Chapter 12 (Planning). Companion definition in William Wake, "Extreme Programming Explored" (Addison-Wesley, 2000), Story Estimation chapter: "We call such an experiment a 'spike solution', to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out." · computer-science
The canonical coining of the term in software engineering. Beck introduces the spike as a time-boxed period to “experiment with a new technology or a new way of solving a problem” — the box bounds the cost regardless of how deep the investigation has to go, and the output is understanding (a feasibility verdict or cost estimate) rather than shippable code. Ward Cunningham’s etymology, captured on the Portland Pattern Repository, frames it as a depth-first metaphor: a spike is “end to end, but very thin, like driving a spike all the way through a log” — contrasted with top-down design’s breadth-first survey.Inference: The spike-solution’s defining structural move is the contrast between exploratory depth (the spike cuts vertically through every layer the eventual build will touch) and throwaway commitment (none of the spike’s code is meant to survive). When a project reaches for the term but intends to keep the code, it has reached for the wrong primitive — that’s a prototype or a minimum viable product, not a spike. The diagnostic transfers: any time-boxed thin vertical slice driven specifically to inform a commit/no-commit decision is the same shape.
FDA 21 CFR §312.21(a) (Phases of an Investigation); ICH E8(R1) "General Considerations for Clinical Studies"; standard treatment in Goodman & Gilman's "The Pharmacological Basis of Therapeutics" (Section I). Phase 1 is defined as the "initial introduction of an investigational new drug into humans" whose explicit purpose is to obtain "sufficient information... to permit the design of well-controlled, scientifically valid Phase 2 studies." · medicine-and-health
FDA 21 CFR §312.21(a) (Phases of an Investigation); ICH E8(R1) "General Considerations for Clinical Studies"; standard treatment in Goodman & Gilman's "The Pharmacological Basis of Therapeutics" (Section I). Phase 1 is defined as the "initial introduction of an investigational new drug into humans" whose explicit purpose is to obtain "sufficient information... to permit the design of well-controlled, scientifically valid Phase 2 studies." · medicine-and-health
A Phase 1 clinical trial is the spike of drug development. The box is small (typically 20–80 healthy volunteers, weeks-to-months duration) and bounded explicitly so that the cost of learning the drug doesn’t work in humans is paid before the much larger Phase 2 and Phase 3 trials are commissioned. The output is understanding — pharmacokinetics, the maximum tolerated dose, the side-effect profile — not therapeutic benefit. Efficacy is not the question; that’s Phase 2’s job. The asymmetric commit-gate at the end determines whether a many-hundred-million-dollar Phase 2/3 program is justified or whether the candidate molecule is killed.Inference: The strict separation of safety-and-tolerability (Phase 1) from efficacy (Phase 2/3) is the regulatory codification of the load-bearing-uncertainty discipline a spike requires. Phase 1 targets the uncertainty that, if it resolves negatively, kills the program cheapest — there’s no point measuring efficacy in a drug that’s toxic. When a domain wants to design a staged investigation, this is the question to ask first: which uncertainty, resolved negatively, kills the program at lowest cost? The cheapest-killing question goes in the first box.
Bill Lennertz & Aarin Lutzenhiser, "The Charrette Handbook: The Essential Guide to Accelerated, Collaborative Community Planning" (National Charrette Institute / American Planning Association). Documents the NCI Charrette System™ as a multi-day (typically 4–7 consecutive days) intensive design workshop structured around a fixed sequence of feedback loops, terminating in a finalized preferred plan. · architecture-and-design
Bill Lennertz & Aarin Lutzenhiser, "The Charrette Handbook: The Essential Guide to Accelerated, Collaborative Community Planning" (National Charrette Institute / American Planning Association). Documents the NCI Charrette System™ as a multi-day (typically 4–7 consecutive days) intensive design workshop structured around a fixed sequence of feedback loops, terminating in a finalized preferred plan. · architecture-and-design
The architectural charrette is the design-discipline form of the spike. A multi-day time-box gathers architects, stakeholders, engineers, and community representatives in one room; the box itself — not the scope of the design problem — caps the investigation’s cost. Stakeholders propose alternatives, narrow them through scheduled feedback loops, and exit with a single preferred plan that has enough resolution to commit the next stage of detailed design and construction-document production. The “pressure cooker” duration is structural, not theatrical: it forces stakeholders past entrenched positions in a window short enough that the commit decision happens while context is still loaded.Inference: The charrette literature’s explicit criticism of “non-charrettes” (any short meeting being called a charrette) maps onto the same anti-pattern a software spike suffers when it loses its time-box discipline — the term gets diluted into “any exploratory work,” and the structural advantage (forced commitment at a known cost) evaporates. The diagnostic question — “what is the commit/no-commit decision this box exists to inform?” — transfers across domains; if no decision is scheduled at the box’s terminus, the activity is research, not a spike.
NASA SP-2003-4531 ("American X-Vehicles: An Inventory from X-1 to X-50"); Daniel Raymer, "Aircraft Design: A Conceptual Approach" (AIAA, multiple editions). The Bell X-1's supersonic flight on 14 October 1947 (Chuck Yeager piloting) is the canonical demonstration that broke the transonic-flight uncertainty before production aircraft (F-86, F-100) committed to designs assuming controllable supersonic flight. · engineering-and-technology
NASA SP-2003-4531 ("American X-Vehicles: An Inventory from X-1 to X-50"); Daniel Raymer, "Aircraft Design: A Conceptual Approach" (AIAA, multiple editions). The Bell X-1's supersonic flight on 14 October 1947 (Chuck Yeager piloting) is the canonical demonstration that broke the transonic-flight uncertainty before production aircraft (F-86, F-100) committed to designs assuming controllable supersonic flight. · engineering-and-technology
The X-plane programs are aerospace’s institutional form of the spike. An X-plane is built explicitly as a research vehicle — not a production prototype — to demonstrate that some load-bearing technological uncertainty can be resolved (the Bell X-1: is supersonic flight controllable? the X-15: can a piloted vehicle reach hypersonic speeds? the X-29: do forward-swept wings work in practice?) before any production aircraft commits to a design that depends on the answer. The box is the X-plane’s lifecycle; the output is a Technology Readiness Level transition (typically TRL 4 → TRL 6); the asymmetric gate is whether the demonstrated technology gets “frozen” into a Preliminary Design Review for a production platform.Inference: Aerospace’s careful terminological distinction between an X-plane (technology-investigation vehicle, throwaway) and a Prototype (pre-production aircraft, intended to become the real thing) maps directly onto the spike-vs-prototype distinction in software. The two carry different commitment shapes — confusing them is structurally identical to a team treating a spike’s code as production-ready. The TRL ladder is the aerospace formalization of “what does the next stage need to know before it commits?”, which is exactly what a spike’s verdict has to answer.
Mike Cohn, "Agile Estimating and Planning" (Prentice Hall, 2005), Chapter 17 ("Scheduling with High Uncertainty"). Cohn frames the spike as a research activity to handle story estimation uncertainty — used when a team cannot converge on a story-point estimate (e.g., a Planning Poker deadlock) because the underlying technical risk is unbounded. · computer-science
Mike Cohn, "Agile Estimating and Planning" (Prentice Hall, 2005), Chapter 17 ("Scheduling with High Uncertainty"). Cohn frames the spike as a research activity to handle story estimation uncertainty — used when a team cannot converge on a story-point estimate (e.g., a Planning Poker deadlock) because the underlying technical risk is unbounded. · computer-science
Cohn’s framing extends the Beck primitive into the agile estimation workflow specifically: a spike is what you reach for when story-estimation itself stalls because the uncertainty around the work isn’t merely large but unknown in shape. The team agrees that they can’t agree, schedules a time-boxed research activity, and returns with enough understanding to estimate the original story with confidence. The spike’s box is sized not to the underlying problem but to the estimation deadlock — its purpose is to dissolve the disagreement.Inference: This sharpens the diagnostic for when to use a spike versus when to push through with a wide estimate range. The signal is meta-cognitive: the team can’t form a coherent estimate because they’re missing structural understanding, not because the work is merely big. A 20-point story with high confidence is a planning problem; a story the team can’t size at all is a spike candidate. The same shape recurs in any planning context where uncertainty is unknown rather than merely large.