RACE Programming
Practice Guide · Measuring a RACE rollout

If your team measures with DevEx

A measurement playbook. For each of the three DevEx dimensions: what to measure under RACE Programming, where to pull it from, what to target, and what to watch. DevEx is the most diagnostic lens on a rollout, because it moves before your delivery numbers do.

The three dimensions, instrumented

Feedback Loops

  • Measure: median time from spec to a passing Definition-of-Done gate, and Inner Cycle frequency.
  • Source: CI logs for gate results, Inner Cycle logs for cadence.
  • Target: gate feedback in minutes; the Inner Cycle running Spec, Build, Align twice per day.
  • Watch: if gate feedback takes hours, the Definition of Done is not automated enough. That is what slows the agent's self-correction.

Cognitive Load

  • Measure: the context a person must hold to move an Executable User Story. Proxies: the return-for-clarification rate on an EUS, and the number of systems touched to complete it.
  • Source: board transitions plus the EUS structure itself.
  • Target: an EUS is self-contained; a Pit Crew engineer can execute it without hunting for context. Everything as Code keeps that context machine-readable.
  • Watch: a rising clarification rate means load is leaking upstream, and the spec is not yet minimum-sufficient.

Flow State

  • Measure: uninterrupted focus blocks per Pit Crew engineer, and mid-Stint re-scope events.
  • Source: focus or calendar tooling, plus board changes within a Stint.
  • Target: long focus blocks and zero mid-Stint re-scopes.
  • Watch: a re-scope event mid-Stint means the Pit Wall is not buffering the client's changes. Fix the boundary, not the schedule.
The tell

DevEx moves before throughput

Delivery metrics move slowly and are easy to game; developer experience moves first and honestly. If a RACE Programming rollout is real, you will see it in DevEx before the delivery dashboard: feedback loops tighten, the context load per story drops, and flow stops being interrupted. If DevEx does not move, the framework is not installed yet, whatever the dashboard says.

DevEx measures the experience. RACE Programming is built to improve all three dimensions on purpose.

Read the framework → · All practice guides →

FAQ

Frequently asked questions

How does the DevEx framework apply to RACE Programming?
DevEx defines three dimensions: feedback loops, cognitive load, and flow state. RACE Programming has a design decision behind each. Feedback loops are the median time from spec to a passing Definition-of-Done gate, tightened by the twice-daily Inner Cycle. Cognitive load is the context a person must hold to move an Executable User Story, lowered by minimum-sufficient specs and Everything as Code. Flow state is uninterrupted focus, protected by role boundaries and the stable Stint horizon.
How do you measure cognitive load in RACE Programming?
Use the rate at which an Executable User Story is returned for clarification and the number of systems a person must touch to move it, as proxies for the context they must hold. The Executable User Story is designed to be minimum-sufficient so the agent builds without re-interpreting context, and Everything as Code keeps state machine-readable, so a rising clarification rate is your signal that load is leaking upstream.
How does RACE Programming tighten feedback loops?
The Inner Cycle runs Spec, Build, Align twice per day, and the four-gate Definition of Done gives a deterministic pass or fail in minutes, so the Silicon Software Engineer self-corrects against the gates rather than waiting for end-of-sprint review. Measure the median time from spec to a passing gate; the target is minutes, not hours.
How does RACE Programming protect flow state?
Measure uninterrupted focus blocks per Pit Crew engineer and count mid-Stint re-scope events. The Pit Wall buffers the Team Principal changes so the Pit Crew executes against a settled spec, and the Stint is a stable horizon, so a re-scope event mid-Stint is a boundary breach and the thing to correct.