Slow Build Lab

Build times are a design smell

2026-09-28 · 4 min

A repository that takes four minutes to tell you it did not compile is not slow because the machine is slow. It is slow because the dependency graph is a ball of string and nobody has looked at it in a year.

I have a small test for this. On a clean checkout, how long until the compiler says the first error? If it is more than thirty seconds, something is being built that did not need to be built, or something is being discovered that could have been declared.

Three things that actually help

One: make the graph visible. A build that cannot be drawn as a DAG is a build that cannot be cached. The tooling to print it usually already exists; nobody runs it.

Two: cache by content, not by timestamp. Nine out of ten "slow CI" stories are timestamp logic that invalidates everything because a file was touched by a checkout.

Three: fail early and loudly. Type checking, formatting and linting should be the cheapest gate, not the last one.

A four minute feedback loop is a four minute tax on every thought you have about the code.

The counter-argument is that build speed is not a product feature. It is not. It is a tax on the people who make the product, and taxes compound quietly until somebody writes a blog post about it.

← All notes