Walking skeleton, tracer bullet, and strangler fig name three patterns that build a thin end-to-end path before they build breadth. The first two overlap and are frequently treated as rivals. The third is a different kind of thing, because it assumes something is already running.
Two patterns that overlap
A walking skeleton is bare-bones end-to-end code that begins a production implementation. Its defining contrast is with a spike, whose code is discarded once the question is answered: the skeleton is kept.
A tracer bullet is a thin end-to-end system that is adjusted through feedback and developed toward the final product. Its emphasis is directional — the thin path exists so that aim can be corrected before volume is committed.
These descriptions overlap, and no dependable boundary divides them. Neither is inherently throwaway. The useful move is to state the purpose and the composition rather than to argue the taxonomy: which components are real, which are substituted, which are missing, and who is competent to judge whether the path is pointing the right way.
What either pattern establishes is that a path connects. What it does not establish is that anyone can do valuable work along it. A repairs application that sends one synthetic request to a database and reads it back has evidence about the storage path. It has none about whether a dispatcher can allocate work, correct a mistake, or hold up under demand.
A pattern of a different kind
The strangler fig migrates legacy behaviour incrementally into a separate new codebase, with seams and a transitional architecture that let old and new coexist. Coexistence is the whole difficulty. Fowler’s account presents four high-level activities and states explicitly that they are not ordered steps.
The costs that decide whether this works are the transitional ones, and they are the items most reliably left out of the estimate: the adapters, the reconciliation, the manual handling, the person who diagnoses a missing or duplicated item. Those need naming, estimating, an operator, and a retirement condition, and they belong inside the increment rather than beside it.
Selecting the candidate on ease of extraction rather than on a stated user or business outcome inverts the pattern. The easiest thing to pull out is rarely the thing whose migration is worth the coexistence cost.
Where to cut
Three decomposition patterns supply three axes for choosing the increment.
End-user segmentation takes a recipient group as the unit, and suits groups with little overlap that use different functional subsets. The check is whether the group is genuinely separable: shared records, permissions, reports, and interfaces all have to have a named owner while this group is on the replacement and everyone else is on the incumbent. A permit office moving renewals staff first discovers that disputed renewals are decided by staff who stay behind, so the dispute handoff and its correction path belong in the acceptance criteria.
Process segmentation takes a bounded portion of a workflow, and suits long processes with batching or handoff points but no stable user-group boundary. The boundary needs an incoming state, an outgoing state, an acknowledgement, and a decision about which side holds the authoritative record.
Competitive system serves a new audience first and uses those results to begin trials with existing users. The limit is what the new audience can test. First-time customers have no standing commitments, so their successful use establishes nothing about migrating customers who have negotiated terms and historical records.
A minimum marketable feature is the value boundary inside any of these: the minimum functionality within a feature that lets a customer perceive value. A usable release can require several together, so the feature boundary and the release boundary are separate decisions.
The rule
What stays fixed is that a thin path is evidence about connection. What changes is whether anything of value travels along it, and that is settled by the work assigned to the slice, not by the shape of the slice.
Where the seams fail
The happy path is the only path traced. A work item arrives, but it also gets rejected, reworked, cancelled, and returned to an earlier stage. An equipment-repair service that moves intake while scheduling stays behind has to carry a corrected identifier forward after initial submission. A trial that handles only first submissions has not tested the boundary it claims to have tested.
Rollback restores the screen and not the writes. Reverting to the incumbent is straightforward for reads and unresolved for everything the new system recorded in the meantime. A recovery plan that addresses the interface and not the data written since the move is not a recovery plan.
A natural break is assumed to be a technical one. An organisational cohort or a workflow handoff looks like a seam on the process map. Whether it is one depends on a tested interface and a decision about ownership, and neither follows from the diagram.
Not to be confused with
A spike. A spike answers a question and its code goes away. A walking skeleton is kept. Using the words interchangeably loses the retention decision, which is the consequential part.
Guaranteed savings. No favourable tradeoff follows from the pattern name. Coexistence has a running cost, and the comparison that matters is that cost against the value of the increment.
A finished architecture. A thin path that works is a reason to broaden it and evidence about nothing broader.