Search The Blog
Latest Posts
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course



This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Mac: keyboard shortcut to enable and disable function keys | Main | Build Pattern: Gated Commit »

Tests and Builds are Made to be Broken

Many agile teams seem to be very focused on not breaking the build. I myself used to jokingly say that your team should have a “I Broke the Build” T-Shirt, to switch between team members.

That was a mistake. I think that builds, much like tests, are made to be broken. Avoiding the public build is like debugging so you won’t have to run your tests. Well ,that last sentence is a bit of hyperbole. It’s like running your tests locally before running them on the build server. Which is actually a great thing to do, unless you can only run some of the tests locally, or it takes time to set up all the integration tests to run on your machine etc.. then it’s just a waste of time. Just run them in the build process. that’s what it’s for.


As time goes on, I see many team members wasting precious time trying to avoid the build, by running it privately, when the whole purpose of the build was to give the indication of failure.

I want to bring forward a small comment I made next to the “Gated Commits” build pattern I wrote about and that will end up in my Beautiful Builds Booklet:

This[pre-tested commits] can lead to an overall feeling in the team that breaking the build is wrong, and is to be avoided at any cost. This might not be a healthy attitude, since the original purpose of a build process was always to find out problems. You might say that if the build breaks, then the build did it’s job. If the build never breaks, why have it in the first place?

The Blame Game:

This culture of “breaking the build is bad, and it’s your fault” can lead to developers hiding their efforts, in an effort not to look stupid in front of their peers. in essence, a private build can lead to moving from a group effort, into individual based comparison system “who breaks the build the most?”.

Lost Productivity:

More problematic: if developers always get the build failing privately, developers will feel they have to solve the build privately. when the build fails publicly, it can trigger help from the rest of the team to solve the problem faster since more brains are involved.

What about making all the other team members wait to commit until the build finally passes? Isn’t that lost productivity? theoretically, yes. but it also is a great reason for the team to help out and make the build pass. It is a “Stop the line” mentality, which we like to adopt in lean circles.


PrintView Printer Friendly Version

Reader Comments (2)

Amen. I've long shared this sentiment. The whole dunce-hat-for-breaking-the-build thing has irked me no end in past jobs.

That said, I do encourage devs to run the build locally too. Not to prevent looking incompetent, but to prevent breaking the build wherever possible. I do not do the gated commit thing that you recommend, mainly because it seems so tooling-specific and a little complicated (I will have to look into it further though).

January 21, 2013 | Unregistered CommenterKent Boogaart

I agree that sometimes it is acceptable to "lean on the build" in the same way that you "lean on the compiler". However there is a fine line between developers just being lazy and not running tests and a genuine break due to something unexpected. If you make it acceptable to break the build "frequently" you are in danger of entering into Broken Windows[1] territory.


January 21, 2013 | Unregistered CommenterChris Oldwood

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics