Skip to content
Time to Signal

Waiting is the largest controllable cost, and almost nobody measures it

A build that takes twelve minutes instead of two costs ten minutes, and then costs the context switch, the batching it encourages, and the checks people quietly stop running. Fifty notes on finding where the time goes and removing it — measuring the system, not the people in it.

All notesStart at the beginning

All 50 notes

Grouped by section, each appearing once. The tag on the left says what kind of note it is.

Foundations

6 notes

Waiting is the subject. Which loops matter, what the delay actually costs beyond the minutes, and the boundary this whole field has to hold: the system is measurable, the people are not the target.

Build systems

8 notes

Where most of the available speed is, and where it eventually becomes architecture work: the graph sets a ceiling that no amount of caching or hardware can lift.

Testing

6 notes

A suite that fails randomly is worse than one that is slow, because it destroys trust in the signal. Reliability is worth more than speed at the margin and is measured far less often.

Pipelines

6 notes

Time to a useful signal rather than total duration. Plus the split almost nobody reports: queue time and execution time have different causes and different fixes.

Local environment

6 notes

The loop developers spend most of their day inside, and the one with no telemetry by default. Includes the friction that costs no measurable time at all.

Measurement

6 notes

Frameworks read as their authors intended, telemetry collected without losing the trust it depends on, and the discipline that turns a number into a change rather than a dashboard.

Running a programme

8 notes

The first ninety days without a purchase, the ranking that returns most soonest, and the failures that recur — each visible early and each with a specific correction.

Reference

4 notes

The boundary: what a fast toolchain does not solve, the requests that would destroy the capability, and a description of the end state to measure a plan against.

What this is

Fifty notes on making a toolchain fast and reliable, written for whoever has been made responsible for it.

No vendor material, no product recommendations, no sponsored content.

Four things that hold across organisations

Waiting dominates and is unmeasured. The time is spread across everyone's day in slices too small to notice individually, which is why it appears in no budget line.

Reliability is worth more than speed at the margin. A suite that fails randomly teaches people to retry rather than investigate, and then the pipeline has stopped being a safety net.

The dependency graph sets the ceiling. Caching, parallelism and faster machines all run out against the longest path, after which the only remaining move is how the code is organised.

Measure the system, not the person. Individual developer metrics measure the environment, are trivially gamed, punish the invisible work, and degrade the telemetry the whole programme depends on.

Where to start

A slow toolchain and no evidence: the measurement section, then the first ninety days in the programme section. No purchase required.

Evidence and no idea what to fix first: the prioritising note.

Someone has asked for per-developer numbers: the foundations, before answering.

A programme that has stalled: the note on common failures.

What this is not

It is not a benchmark to compare against. No industry figures are quoted, deliberately: comparable numbers depend on codebase size, language, deployment risk and definitions, and published ones are self-selected.

Every number worth having is your own, measured the same way twice.