Eric Lefevre-Ardant on Java & Agile

I had suggested a topic covering “Beyond Installing CruiseControl – CI Culture with Management and Developers”. It actually got merged with “Social Impact of CI”, suggested by Michael, and “How to introduce CI”, from Jeffrey. Jeffrey had, in fact, a presentation that he had already discussed in a previous conference, so most of the session ran around it.

Michael reported that he had witnessed situations where the developers distrusted their management so much that they were quite opposed to CI in general, figuring that it would be used to identify and fire people that break the build often. It could be said that the culture of blame was already there, though.

Jeffrey’s presentation argued that changing habits is extremely hard. He quoted a sociologist who wrote that “familiarity exerts a powerful force”. Essentially, people rather do something that is painful, but that they know about, rather that something better that they do not know.
To leave this vicious circle, one solution is to give small bonuses to the developers. For example, give one sticker per unit test written. The personal impact of this is important; people would probably not do it for money (which would have to be small amounts anyway), but they would do it when it makes them feel good. Douglas commented that he couldn’t imagine doing this sort of things with his team, as it would be perceived as childish (maybe giving tickets for a beer at a company party who work better?).

I think the root of the matter is that constant vigilance is paramount. Basically, it is not possible to simply tell people to write unit tests, or to install CruiseControl. Some will probably start doing so, but precious few will keep on doing for good. Those that do, however, should probably be used as relays to remind the other developers to keep on writing tests, and add new techniques and tools.

That reminds me of a study on productivity. A consultant had realized that, in a factory, productivity would go up when the light is stronger. However, he also noted that, when the light was dimmed, productivity would *also* go up! The point is that productivity increases when people feel that someone is paying attention to them. Or maybe it is the simple fact of changing something in their environment which prevented them from sinking in monotony.

Notes on the session are available on the CITCON website.

I have older posts on CITCON.

Update: quoted sociologist is Virginia Satir.

I was generally impressed by what people seems to have put in place for Continuous Integration. Here is a list, from the top of my head:

• load testing; Douglas Squirrel from youDevise told how they were using CruiseControl to trigger a (simple) load test scenario. The test environment is not perfectly representative, and the build does not get broken when it fails. However, a web page gets updated, which helps in having an idea of the *change* in performances. As an interesting twist, they are loading real time quotes from Reuters.
• functional tests: considering that they usually take a long time to run, the consensus is that it is not smart to run them along with the unit tests. The solution is to have “very frequent” build that gives quick feedback to the developers. And, on the side, have “very complete” build that does as much test as possible.
• “pipelines”: some people wanted to manage an order in the builds run by CruiseControl. ie. “run this build (client application) only after this one (framework) has been run successfully”. Apparently, some worked around this by getting the first-order build to commit a file in the version management system, which would be detected by the second build.
• Mike from Atlassian explained that they felt the need to get more metrics from their builds. They managed to put together a system that would store various information to a database, which could later be queried. This is to be released eventually as a product, codenamed Bamboo.

The Bamboo thing sounds nice, but wouldn’t it be even better to store many other data, such as the number of developers over time, the number of commits, etc.? Some data could be obtained by a tool like Bloof, others from the bug tracking system… The grand plan would be to obtain a huge wealth of information, which could then be exploited by a manager, maybe even with the help of a data analyst. And then, some tendencies would be infered by some brilliant Levitt-wannabe! I can’t wait ;-)

I have an older post on CITCON.