Last weekend I attended the Continuous Integration and Testing Conference (CITCON), which was held in Wellington for the first time. Paul Julius and Jeffrey Fredrick hosted their 13th conference and put on a great show, surprisingly by stepping back and letting the participants take over.

This was the first open space conference I’ve attended and I was astonished by how well it all worked out. I can definitely recommend participating in a CITCON and in open space conferences in general. Just be prepared: Make sure to have a think about what you would like to get out of the conference and what topics you would like to hear and talk about. The idea of open space is that the participants decide what is happening. If you improvise well you can, of course, do this on the fly. However, if you are like me, you prefer thinking about it ahead of time.

My main “take away” had surprisingly nothing to do with Continuous Integration or Testing. It was the realisation that there are different flavours of Pair Programming. It seems obvious now, but I never thought about it like this. I needed PJ to give them names to point out the obvious. The techniques he described were

• Ping Pong: One developer writes a failing unit test, the other makes it pass and writes a failing unit test as well. The first fixes it and writes another failing unit test… and so forth. You get the drift. This practice is suitable for a pair of developers that are at about the same level of expertise, both technically as well as with knowledge of the code under development and business rules.
• Ball & Board: One developer gets the mouse, the other one gets the keyboard. The ruler of the mouse should be the more experienced developer and steers the design and direction of the code under development as he is the only one allowed to choose what to do next. The developer at the keyboard writes the actual code.
• Batting Practice: In this practice the ‘trainer’ throws an imaginary ball for the ‘batter’ by writing a failing unit test. The ‘batter’ hits it by writing the code to fix the test. This practice can be used when a more senior developer is introducing a junior developer to a new development concept, say test driven development.

Note that in all of the above practices the driver and the passenger roles change frequently, which in my opinion is crucial to keep the the developer in the passenger role engaged and focused.

Another idea that I found interesting, came up when we talked about how distributed version control systems like Git actually work against the concepts of continuous integration. PJ noted that he has been toying around with the idea of distributed continuous integration. A distributed CI tool would run on the developers machine, just like each developer has a clone of the repository. The local CI tool would then integrate the local changes with the trunk and let the developer know what would happen if he were to push his changes to trunk. There could be a setting to do this automatically, if there are no failures.

All in all, the conference was a great success. I thoroughly enjoyed it.