A3.7 · The roadmap layer
The tracer bullet
Ship one thin thread through every layer first, kept and grown — not a layer built fully, and not a prototype to discard.
A roadmap stays honest about uncertainty when it threads one thin slice end to end
before deepening any layer. The exemplar is the Portal's real web chapter —
F6 (Phoenix): its tracer is rung f6.1, the engine served
as a web app (request → facade → render), shipped before persistence
(f6.3) or the rendered catalog (f6.5). Walk the
ladder on the right to find it.
Walk the F6 ladder · find the tracer
Thread first, then depth
A backlog can be ordered two ways. Breadth-first builds each layer fully — the whole data layer, then the whole facade binding, then the whole view — and integrates last, when the most risk is left to discover. Depth-first ships one thin thread through every layer first: a tracer bullet. The thread proves the seams on day one, and every later rung deepens the slice that already works.
On the Portal's web chapter F6, the tracer is rung f6.1: the engine
served as a web app — a request enters the endpoint, calls the Portal
facade, and renders a page. Its demo is “hit the root, see a page”; its harness is a
single GET smoke. It is shipped before persistence (f6.3) or the
rendered catalog (f6.5), and it is a real thin feature that is kept and
grown — not a prototype to throw away. Every rung holds the master invariant: “The web
layer calls only the Portal facade and renders only the closed
%Portal.Error{} set.”
Ship a thin end-to-end thread first — a tracer bullet — to de-risk integration early; keep it and grow it. A prototype is built to learn, then discarded.
F6.1 is the tracer — the engine served as a web app (request → facade → render), kept and grown into the live platform. A prototype of it would be discarded once it answered its question.
The tracer is the rung you keep and grow; the prototype is the rung you throw away.
The three dives
Each dive takes one move of the technique, in the arc end to end first → tracer vs prototype → deferring breadth: first why the thread ships before depth, then how to tell a tracer from a walking skeleton and a prototype, then how deferring breadth keeps the roadmap honest about uncertainty. Read them in order — A3.7.1 starts.
End to end first
A thin thread through every layer first (F6.1) to de-risk integration early — why threading beats building one layer fully, and how it pays the riskiest bill first.
Tracer vs prototype
A tracer (a real thin feature, kept and grown), a walking skeleton (end-to-end structure, no feature yet), and a prototype (built to learn, then discarded) — told apart.
Defer breadth
Defer breadth deliberately; depth follows the thread; name every seam you defer — the way a roadmap stays honest about uncertainty.
A3.7 grounds the technique on the orientation dive A3
· The roadmap layer, and on the real phoenix.roadmap.md read in
A3.3 · Anatomy of a roadmap.md.
Return to the A3 chapter navigation to continue.
References
The delivery-planning tradition the tracer-bullet technique draws on, and where it connects in the course.
Sources
- Hunt & Thomas — The Pragmatic Programmer — tracer bullets and walking skeletons: a thin thread through the whole system, kept and grown, distinct from a throwaway prototype.
- Humble & Farley — Continuous Delivery — releasing thin, demoable slices down a delivery pipeline, integration paid down early.
- Beck, K. — Extreme Programming Explained — small releases over an ordered backlog, the most valuable thread first.
Related in this course
- A3.7.1 · End to end first
- A3.7.2 · Tracer vs prototype
- A3.7.3 · Defer breadth
- A3 · The roadmap layer — the chapter this module sits in.
- A3.3 · Anatomy of a roadmap.md — the real file the tracer rung lives in.
- 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 F6.1 first ships, layer by layer.