The Cost of Waiting

The obvious cost of a ten-minute build is ten minutes. The real cost is larger and mostly indirect.

The direct cost

Duration multiplied by frequency multiplied by people.

Worth computing once, from your own data, because the number is usually larger than anyone expects and it is the easiest part of the argument.

It is also the smallest of the costs below.

The context switch

Feedback that arrives after a certain delay is feedback the developer is no longer waiting for.

Under roughly ten seconds, attention holds. The developer is still in the problem.

Up to a minute or so, attention wanders but returns cheaply.

Beyond a few minutes, the developer starts something else. Coming back means reloading the whole mental state of the change.

The reload is the expensive part, and it is not proportional to the wait. A twenty-minute build does not cost twenty minutes; it costs twenty minutes plus the cost of having left.

The batching effect

The second-order consequence, and the one that does the most damage.

Slow feedback makes people batch. If verifying a change takes twenty minutes, you do not verify one change — you make five and verify them together.

Larger batches are harder to review, harder to debug when they fail, and more likely to conflict.

Failure localisation gets worse. When a batch of five changes fails, you know one of them broke it. Finding which costs more than the five individual runs would have.

This is why build speed affects code review quality, which is a connection people rarely draw.

The checks that stop running

The quiet cost.

Developers skip the slow step. They push without running the full suite locally, because the full suite takes eleven minutes.

They stop using the linter if it adds noticeable time to save.

They retry rather than investigate a failure, if investigating means another twenty-minute cycle.

The tooling is still there. It has stopped being used, and no metric reports that.

The reliability multiplier

Slow and unreliable interact badly.

A flaky test in a slow suite means a retry costs the full duration again. The rational response is to retry immediately rather than to investigate, which means the flake is never fixed.

Trust in the signal drops, and once a red build is assumed to be noise, the pipeline has stopped being a safety net.

Reliability is worth more than speed at the margin, and it is measured far less often.

Sizing it honestly

Do not multiply build minutes by an hourly rate and present it as a saving. Nobody believes it, and the developers whose time it is will tell you it is not how their day works.

Measure what is checkable: total wait time per developer per day, batch size, changes per developer per day, time from push to signal.

Show the trend after a change, on the same measure.

Report the batching effect where you can see it: average changes per pull request before and after a build speed improvement is a compelling number and it is directly attributable.

The batch size measurement

The most persuasive number available and the easiest to compute.

Changes per pull request, median, over time.

Plot it against blocking pipeline duration on the same axis.

The relationship is usually visible. As feedback slows, batches grow, because verifying costs enough that people stop doing it per change.

It is directly attributable, which is what makes it useful: a build speed improvement followed by a fall in batch size is an effect you can point at without claiming a productivity percentage.

Report both numbers together, always.

The number not to compute

Resist the temptation, because it will be challenged and it will not survive.

Build minutes multiplied by an hourly rate assumes saved time converts to output, which nobody believes and which the developers themselves will dispute.

It also invites the counter-argument that people work on something else while waiting, which is partly true and ends the conversation.

Report the batch size, the compute bill and the onboarding days instead. All three are checkable, none requires a conversion factor, and together they are more persuasive than a large unfalsifiable figure.