Tracer vs prototype

Three thin-looking artifacts, told apart on two axes: does it carry real feature value, and is it kept or thrown away.

A tracer is a real thin feature, kept and grown. A walking skeleton is the end-to-end structure with no feature in it yet. A prototype is built to learn one thing, then discarded. On the Portal, f6.1 is the tracer — kept and grown into the live platform. Pick one on the right to read its profile.

The three artifacts Kept vs thrown away On the Portal References

Classify the three · two axes

Tracer · real feature: yes (thin) · fate: kept and grown · F6 example: f6.1 (the engine served as a web app). A real thin slice you keep — the opposite of a discarded prototype.

Three artifacts, two axes

The three are easy to confuse because all three look thin. They separate cleanly on two questions. Does it carry real feature value — a path a user could actually take? And is it kept — grown into the shipped product — or thrown away once it has done its job? A tracer answers yes and kept; a walking skeleton answers no and kept (the structure survives, the feature is still to come); a prototype answers no and thrown away.

tracer: A tracer bullet — a real thin feature, threaded end to end, kept and grown. It carries one real path through the system.
skeleton: A walking skeleton — the end-to-end structure with no feature in it yet: the layers wired together with a placeholder where the behaviour belongs.
prototype: A prototype — built to learn one thing (does this approach fit?), then discarded. Its value is the answer it gives, not the code it leaves.

The danger is the prototype that is never thrown away: a throwaway spike reused as the foundation makes a draft into the product by accident. A tracer is built to be kept; a prototype is built to be discarded — keeping that distinction is what stops the mix-up.

Kept vs thrown away

The sharpest difference is fate: how much of each survives into the shipped platform. A tracer is kept whole and grown — all of it lives on. A walking skeleton's structure survives, but it carried no feature to keep. A prototype is discarded once it has answered its question; reusing it is the mistake. The figure reports the kept fraction for each, over a fixed model.

The two interactives teach different moves: the hero places each artifact on the two axes, this one measures how much of each is kept. Pick an artifact and read the survival bar.

Kept into the shipped platform · pick one

Tracer · kept into the shipped platform: 100% · built to be kept and grown. F6.1 is grown by every later rung — none of it is thrown away.

A tracer is kept whole; a prototype is kept at zero — built to be discarded once it has taught its one thing.

The tracer, on the Portal

On the Portal, rung f6.1 ships a real, if thin, feature: a request renders a real page from the real Portal facade. It is kept — every later rung grows it. A walking skeleton, by contrast, would wire the endpoint to the view with a placeholder where the facade call belongs: structure, no behaviour. A prototype would be a throwaway spike to answer one question and then be deleted. F6.1 is neither.

The distinction matters because the three are built differently. A tracer is built to production quality from the start, because it stays; a prototype is built fast and loose, because it goes. Treating a prototype as a tracer ships a draft; treating a tracer as a prototype throws away work that was meant to be kept. Every rung holds the master invariant: “The web layer calls only the Portal facade and renders only the closed %Portal.Error{} set.”

# The three artifacts, told apart on two axes.
#   artifact          | real feature? | kept or thrown away?
#   tracer (f6.1)     | yes (thin)    | kept and grown
#   walking skeleton  | no            | structure kept, no feature
#   prototype         | no            | thrown away after it teaches

artifact   = "tracer"
real_feature = true     # f6.1 renders a real page from the real facade
kept         = true     # grown by every later rung — not discarded
example      = "f6.1 — the engine served as a web app"

# A prototype would be kept = false: deleted once it answered its question.

the principle

A tracer is a real thin feature, kept and grown; a prototype is built to learn one thing, then discarded. Tell them apart so a draft never becomes the product by accident.

on the Portal

F6.1 is the tracer — the engine served as a web app, kept and grown into the live platform. A prototype of it would be thrown away once it answered its question.

Keep a tracer, throw away a prototype — and never let one become the other by accident.

Recap — kept, or thrown away

Three thin artifacts separate on two axes. A tracer carries a real thin feature and is kept and grown. A walking skeleton is end-to-end structure with no feature yet. A prototype is built to learn and then discarded. On the Portal, F6.1 is the tracer. The next dive turns to what happens after the tracer ships: how depth follows the thread, and how deferring breadth keeps the roadmap honest about uncertainty.

Next in A3.7: A3.7.3 · Defer breadth — grow the one thread, defer breadth deliberately, and name every seam you defer.

References

The sources behind the tracer / skeleton / prototype distinction, and where it connects in the course.

Sources

Hunt & Thomas — The Pragmatic Programmer — tracer bullets vs prototypes: the thin thread you keep against the spike you throw away.
Humble & Farley — Continuous Delivery — production-quality thin slices, kept and grown down the pipeline.
Beck, K. — Extreme Programming Explained — the spike solution: a throwaway experiment to answer a question.

Related in this course

A3.7 · Tracer bullets and walking skeletons — the module hub.
A3.7.1 · End to end first — the previous dive.
A3.7.3 · Defer breadth — the next dive.
A1.02 · The pragmatic case — the pragmatic roots of the technique.
F6 · The Portal on the web (Phoenix) — the real chapter whose tracer is F6.1.
F6 · The request lifecycle — the thread the tracer first ships.