Glossary

Blocking pipeline — the checks that must pass before a change can merge. Distinct from work that runs after merge or on a schedule, and the split is a risk decision that should be explicit.

Cache hit rate — proportion of cacheable tasks whose results were reused. The single most diagnostic number in a build system, and low rates almost always trace to non-reproducibility.

Critical path — the longest chain of dependent tasks. Sets the floor on build duration regardless of how much parallelism is available.

Escape rate — failures caught by a full run that test selection skipped. The correctness measure for selection, and the one almost nobody tracks.

Flake — a test that fails and then passes on the same commit with no code change. Mechanically detectable, given per-test result history.

Hermetic — a build whose result depends only on its declared inputs. The property that makes caching safe.

Incremental build — reusing results of unchanged tasks. Depends entirely on inputs being declared correctly; overdeclaration is the common silent failure.

Lead time for changes — commit to running in production. The DORA measure that everything in these notes contributes to.

Merge queue — a mechanism that tests each change against the state it will actually merge into, rather than the state it was written against.

Queue time — from a run being triggered to it starting. A capacity problem, distinct from execution time, and routinely reported as part of it.

Rebuild breadth — how many modules a typical change invalidates. Predicts everyday experience better than any single duration.

Test selection — running only the tests affected by a change. Needs a safety net and an escape rate.

Time to first useful signal — from push to the developer learning something actionable. More useful than total pipeline duration and rarely measured.

Terms used loosely elsewhere

"Developer productivity" covers system performance, delivery throughput and individual output. These notes mean the first, say so, and argue against measuring the third.

"DORA metrics" are team and system measures. Applied to individuals they are a misuse the framework's authors have warned about explicitly.

"Build time" is quoted as one number and is at least three: cold, warm and incremental. They differ by orders of magnitude.

"Flaky" is used for anything intermittent, including genuine race conditions in the code. Half of flaky tests are correctly detecting a real bug.

"Platform engineering" and this work overlap and are not the same. One builds the paths; this is about how fast they are.

"Coverage" is a diagnostic. As a target it reliably produces tests that assert nothing.

How to read these notes

A short orientation for anyone arriving at the collection rather than at one page.

Start with the foundations if the subject is new, particularly the note on which loops matter and the one on not measuring people.

Start with measurement if you have a slow toolchain and no evidence.

Start with the build section if you know where the time goes and it is compilation.

Start with common failures if a programme has stalled.

The reference section states the boundaries — what this work cannot fix, what to refuse, and what a working arrangement looks like.

Nothing here is a benchmark to compare against. Every number worth having is your own, measured the same way twice.

On the numbers in these notes

A short note on how to treat any figure here.

No benchmarks are given, deliberately. Comparable numbers depend on codebase size, language, deployment risk and definitions, and published figures are self-selected.

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

The orders of magnitude offered — subsecond editor feedback, seconds for an incremental build, minutes for blocking CI — are directional and not targets.

Where these notes state a relationship rather than a number — faster feedback produces smaller batches, unreliable signals produce retries rather than investigation — that is the part worth relying on.