Why Are Build Breakages Painful?

Before diving into the helpful practices, a review of the core reasons teams strive to avoid broken builds will provide some context. Professionalism is the most basic reason to avoid broken builds. As software developers, we are supposed to deliver working software to our customers. If we are sloppy enough to be unable to even compile, we are failing pretty seriously.

That said, the most fundamental pain point is evident when a compile error in a project interferes with the rest of the team getting their work done. Being unable to compile your project to test your changes or debug an issue is extremely frustrating. Reaching this state will cause developer productivity to plummet for most teams. Getting work done is more difficult for the most focused, and many developers will just open a web browser in frustration and surf a bit while they wait for the build to be fixed.

Meanwhile, the stream of new things to test, in automated functional testing or manual QA, seizes up. Without new builds, there's nothing to test. Human testers can usually find something moderately useful to do, but that team and the automated functional tests will be unable to discover defects introduced since the build started failing. The closer the defect is detected to when it is introduced, the cheaper it is to fix. A broken build lengthens that time. Likewise, other developers on the team are unable to properly integrate their code and test their changes against each other. While the build is broken, Continuous Integration stops, along with its benefits.

Absolutely critical to all of these issues is the frequency and length of a breakage. If a project build is always broken, developer progress will always be slow as they spend more and more time trying to fix the build. Eventually, all improvements to the application and testing grind to a halt. Almost as frustrating is the intermittent broken build. More times than not, these breakages give no clear visibility into the current state of the build, making it difficult to diagnose. In this situation, many a developer fears to update his workspace with the latest code, and rather chooses to integrate his work occasionally: largely undermining Continuous Integration initiatives.

All this time spent unable to perform testing and integrations inevitably leads to more broken builds, inflicting a vicious cycle in which morale falls and projects fare even worse. The problem is compounded in global development environments where a developer breaks the build and goes home, unaware of the problem until the next day. Meanwhile, several other development teams have been impacted for their entire working day. It is critical to avoid this cycle which leads many teams to live in fear of any broken build. The best practices supporting pain free building are geared around helping teams avoid these cycles.