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.

If the build never breaks, why have it in the first place? interesting bit on pre-tested commits osherove.com/blog/2013/1/20…

— Ken Egozi (@kenegozi) January 20, 2013

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.

Thoughts?