Use a spike to resolve a decision rather than decorate it

What This Concept Is

A spike is a bounded investigation of a decision-changing uncertainty. Its output is evidence and a decision, even if the experimental code is discarded.

Why It Matters Here

An impressive prototype can consume the entire scope budget while leaving the riskiest assumption untouched.

Concrete Example

Suppose a third-party sandbox might not support the required idempotency key. Before building the full UI, test duplicate and timeout behavior in a controlled adapter. Record documented guarantees separately from observations. If the assumption fails, select a safer interaction or reduce scope instead of hiding the uncertainty behind retries.

Common Confusion / Misconception

One successful request does not establish a contract. A mock proves behavior you wrote into it, not the external service. A spike without a stop condition tends to become unreviewed production code.

How To Use It

State hypothesis, alternatives, bounded effort and decision thresholds before running. Preserve negative results, data provenance and environment limits. Record whether experimental code is retained, replaced or discarded.

Check Yourself

What decision changes if the result is negative? Which external guarantee is still untested? When do you stop?

Mini Drill or Application

Choose the highest-risk dependency and produce two possible outcomes with the resulting architecture choice. Execute the narrow experiment and update the ADR.

Read This Only If Stuck

Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.

C4 model; Google engineering review guidance. Revisit Semester 07 quality, domain and review lessons; no new book is required.