Build Times Are a Culture Problem

The argument for fast builds is usually made in arithmetic: developers wait four minutes, twenty times a day, across a team of thirty, so here is the annual cost in salary. The arithmetic is correct and it understates the problem, because the real damage is behavioural rather than temporal.

What slow feedback changes

When verification is expensive, people batch. Instead of one change and one check, developers make five changes and check once, which means when something breaks they have five suspects. Debugging time rises non-linearly with batch size, and the batching was a rational response to the slow loop.

Worse, expensive verification suppresses experimentation. Trying something speculative costs a coffee break, so people stop trying speculative things and stick to the approach they are confident about. The cost of that is invisible and probably larger than the waiting.

Where the time actually goes

• Cold starts that could be warm, because caching was never configured properly.
• Test suites run in full when a dependency-aware subset would cover the change.
• Sequential stages in pipelines that have no actual dependency on each other.
• Environment setup repeated per job instead of baked into an image.

Most pipelines have never been profiled, which is remarkable given the effort teams put into profiling application code that runs less often.

Targets worth defending

Local feedback on a single file change should be near-instant. The unit test suite for a module should run in seconds. The full pipeline to a mergeable state should sit in single-digit minutes, because beyond roughly ten minutes developers context-switch to something else and lose the thread of what they were doing.

Any feedback loop longer than a coffee refill will be routed around rather than waited for, usually by testing in production.

Making it stick

Treat build duration as a tracked metric with an owner and an alert when it regresses, the same as any user-facing latency. Pipelines get slower one commit at a time, and without a watch on the number, the team adapts to each small increase until the loop is intolerable and a heroic project is required to fix it.

The teams with fast builds are not lucky. They are the ones who decided it was somebody's job.