My entries on continuous integration continue to attract attention and comment. William Caputo had some insightful things to say:

...there are few larger anti-patterns on an Agile/XP project, in my experience, than the dreaded (and worse, tolerated/expected/blessed) long automated-build times. It's unacceptable on my projects... Ironically, by making certain things easier, automated tools can push the point where [long builds] get too painful to tolerate, well into the realm of "very expensive to fix" making it more--not less--important that the team that uses these tools understands continuous integration (sorta like using a refactoring browser without understanding refactoring, but worse).

I really like Bill's point that continuous integration tools make long builds less painful, making them more expensive to fix. This is exactly the point I've been trying to make.

There's an old joke. It goes like this:

To err is human. To really screw up, you need a computer.

Continuous integration tools make it easier to really screw up. As Bill says, there are few larger anti-patterns than long automated build times. A continuous integration tool will allow you to put up with a long automated build long past the point where it's easy to fix.

On the other side of the coin, Steven Newton has a story that counters my comment that the whole team should commit to the continuous integration attitude before putting a tool in place. He tells about a time when he used the tool to help people see the value of continuous integration:

When I introduced CC into the environment I took a very light touch in pounding the bozos. I did not get everyone's approval or acceptance of responsibility at first.

I did a first push, "hey everybody you need to get on board with this", and then I left it alone for a while. We had a lot of broken builds at first, but every once in a while we'd get one that worked. I left the setup so that failed unit tests would not fail the build, so that a complete build would generate an email showing the failing unit test results. After a while, one or two of the developers started to care about what the results where. I still didn't push anything, I just offered the observation that the automated build was just there to "help us when we fall down". I did a lot of gentle communication using the results of the build as a reference for my observations.

I'm happy to say that after a while the team members themselves began, one by one, to value the feedback. It sort of grew organically, without a lot of wailing and gnashing of teeth. Eventually, team members were actively depending on the build and motivated to be sure checkins were clean and tests were passing.

It seemed to me that it was not much use to tell the team of the value of CI up front, but that putting CI into use as a tool to be used for its feedback to the team lead to its endorsement without holding anyone's feet to the fire.

This is a good story, and I can see how it would work. It would take a lot of patience and I'm not sure I have that much. :)