Plunger

I have talked with several customers recently about the benefits of using Continuous Integration (CI) practices as part of your development process. I am a big believer in continuous integration as I have seen the software quality greatly increase on several projects that have implemented the practices. The only thing that I have seen increase the quality more is a good base of unit tests and the good base of units tests is pretty much a prerequisite for CI (you can do CI without unit tests, but you are not realizing a fraction of the benefits).

One of the key benefits of CI is that it makes everyone pay attention to the build as a vital part of the process. When the build is done by a dedicated person, the Build Master as they are sometimes called, you don’t get that sense of ownership. When the team I was on first implemented CI, we wanted to create the sense of ownership in every person on the team. We also wanted people to take the build seriously, even if it was just an interim CI build. We also wanted to have a little fun with it, so we bought a plunger.

We had a very simple team rule: anyone who broke the build would have to have the plunger visible on their desk from the time that they broke the build until the next person broke the build. There was a bit of shame involved in this, but it was meant to make you more aware before you committed code into the system. At first we noticed the plunger moving around quite a bit. As time went the team started following better practices: getting the latest version more frequently, adding additional unit tests and running the build locally before committing source. The plunger moved less frequently which also motivated the team to increase their quality, because if you broke the build you knew you were going to have the plunger for a while.

These were the obvious benefits that you would expect from people paying attention to the build. The unobvious benefit was how much more aware that the developers on the team became of the dependencies on each other’s work. You might commit a change and it work fine, but a corresponding change in another developers code could cause the build to fail later (our plunger rule involved root cause analysis and you could inherit the plunger after the fact even if your change did not break the build right away). This increased the communication among the developers on the team, which almost always increases quality.

So you want to increase your code quality, one of the best investments you can make is a $3.00 plunger. And please, don’t try and save a few bucks by grabbing one out of the janitor’s closet. 🙂