The Fallacy of the Ever-Green Build

The fallacy of the ever green build is built on top of good intentions and hyperbole. Let's start with getting some of the preliminaries clear, these behaviors are strictly "not ok"

• Checking in code that is known to be broken.
• Not taking responsibility for fixing the build once broken, by yourself or by asking for help.
• Not helping a team-mate stuck on how to fix the build.

Given that these clearly defective behaviors aren't present, and under the assumption that you have a normally stable build process and a decent enough build machine, the fastest machine affordable is a good advice. Then given the commandment "thou shalt never break the build" or "when you break the build God kills a kitten", most don't respond with enlightenment, they figure out "good" ways to not break the build:

• Writing fewer tests, tests not present never breaks the build
  • prime example is not verifying behavior of common components or leaving them underspecified.
• Delaying checkins far longer than necessary "to make sure", waste full since it squanders time that could have been used for better things
• Not working, no work = no code = no broken build.

If you're using the fastest machine in the building to display a green light, you're not making good use of that investment. On the other hand, if you use it to find valuable but seldom occurring problems in a way that is less costly than the alternative then it's a good investment. That basically entails loosing up a bit on the "run every test we got! never break the build" in favor of "run the fast, high coverage tests most likely to yield sufficient certainty the soundness of your commit". There's learning to be had from every build failure, the only thing you learn from "green" is that you're probably hiding problems. Now I'm talking about a small controlled amount of high information build failures, missing files and not bothering to spend a couple of minutes to run the tests for the area just changed don't qualify.