Ten-Minute Build

Ten-Minute Build is the XP practice of keeping the automated build of the entire system, tests included, inside ten minutes.

The number is arbitrary and that is a feature. It is short enough that you will run the build rather than guess, and long enough to be achievable, which makes it a budget rather than an aspiration. Its real function is as a constraint on everything upstream: a suite that cannot fit the budget forces the team to fix the slow tests, the slow build, or the coupling that makes both slow, at the moment the problem appears rather than a year later.

It is listed immediately before Continuous Integration in the book, and the ordering is not accidental. Integrating many times a day is only tolerable if verifying an integration is cheap. Ten minutes buys you roughly hourly integration without the build becoming the thing you schedule your day around.

The same argument, one level down, is the case for fast tests: speed is not a nicety, it is the precondition for the tests being run at all. The ten-minute budget is that argument given a number and applied to the whole pipeline.

Signal: you know the current build time, and a change that pushes it past the budget gets treated as a defect.

Sources

• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004): Ten-Minute Build is a primary practice in chapter 7, listed immediately before Continuous Integration, per the published table of contents.
• Martin Fowler, Continuous Integration: the automated build as the verification step CI depends on.