A platform's pipeline is reliable but slow, and developers batch changes to avoid it. What is the real cost, and what should be measured?

The real cost

Batching, and everything that follows from it.

A slow pipeline makes developers accumulate changes before pushing. Larger changes are harder to review, more likely to contain a defect, harder to bisect when one appears, and produce bigger merge conflicts. The pipeline did not just delay the work; it changed how the work is done, for the worse.

The second cost is context switching. A developer waiting forty minutes for feedback starts something else and returns with the context gone. That is the dominant cost of a slow pipeline and it is far larger than the compute.

What should be measured

Time from push to actionable feedback, at the percentile developers actually experience. A mean of four minutes with a p95 of forty means most developers have context-switched, and the mean is hiding it.

Then:

• Failure rate of the pipeline itself, distinguishing genuine failures from flakiness. A suite with known-flaky tests trains everyone to re-run rather than investigate, which destroys the value of every reliable test in it.
• Queue time versus execution time. If most of the wait is queueing, the fix is capacity or prioritisation, not faster tests.
• Change size distribution, which is the symptom of batching and the leading indicator of everything else.
• Time to restore after a bad change, since a fast pipeline is also the fastest rollback path.

The fixes, in order

1. Fast feedback first, comprehensive later. Unit tests and static checks in the first minutes; the full suite after. Developers get actionable feedback quickly, and the slow parts do not block the loop.

2. Test selection. Run what the change could affect, with a full run on merge.

3. Cancel superseded runs, which is frequently the largest and cheapest capacity recovery.

4. Parallelise and cache, with layer ordering stable-to-volatile so a code change does not re-resolve dependencies.

5. Quarantine flaky tests immediately and fix or delete within a defined window.

The framing

Pipeline speed is a change-size control. It determines whether the organisation ships small changes continuously or large ones occasionally — and every other delivery property follows from that.