I’ve been a little bit quiet on the blogging front, both personal and work related (or at least it feels that way). The last few weeks have been busy, as I’ve been getting back into my normal routine (riding heaps!) coupled with the preparation of two major presentations. The first of these, intended for an audience internal to my company for this weekend, has had most of my attention for the better part of last month. The second, which had been the focus of this month, was for the Agile India conference that I had been accepted into. This presentation (more like a workshop), titled, “Priming the Pair Programming Practice For Production” (I couldn’t resist the alliteration), was aimed at providing an environment for people to experience pair programming first hand, with the benefits of coaching that would usually be lacking in the workplace.

I had been designing the session to expose people to both the benefits and challenges associated with this practice that is best learned with hands-on experience. Unfortunately for me, due to a whole series of recent events and bad timing, I have had to withdraw from the conference.

Now that I will not have the chance to actually run my workshop, I may as well describe what had been planned. In addition to going over the thinking behind pair programming, all of my exercises had been designed to give as much practice as possible, coupled with constant feedback, to pair programming and other agile practices. The first two exercises were intended to be fairly trivial, a programming problem to be tackled in pairs, the second, a pair programming refactoring session. I was probably most looking forward to the third exercise (especially from the participant’s reactions) which I had named “Pair Pong”, after the game “Ping Pong”, combining pair programming with the agile practice of Test Driven Development (TDD). Much like the real game, a token (in this case, a keyboard) would be constantly passed around between the pairs. One partner would write a test case to represent a requirement out of a given list, while the other would write enough code to get it working. The roles would swap and the game would continue until all the requirements were complete, with the aim of the pairs to only ultimately communicate via the code they passed between each other.

Although the “Pair Pong” concept is not new, I think associating it with something that everyone can relate to can make it easier to actually implement. I’m sure I’ll have an opportunity to run with this workshop one day; I just know it won’t be next week.