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.

The other day, I commented on how I had participated in my first proper pair programming session. Compared to the “pairing” session I had back in November, (where I was, more often than not, the back seat passenger instead of Navigator) this experience beat it hands down. As keen as I have been in the past to attempt pair programming, project constraints have never really been conducive to real pair programming. Luckily I had been preparing for this opportunity unwittingly by reading “Pair Programming Illuminated“. The book that Brett had kindly loaned me was an excellent resource for describing constraints that hinder and identifying techniques to improve pair programming practices. Read more “On Pair Programming”

I’ve been working on a story card that is part of the “critical path” by enhancing a framework not really designed for what we need it to do (not that they ever are). I have almost no test coverage, very little documentation and a completely different architecture and context to work in. I think that after today, I can honestly testify to my first proper pair programming experience. I intend to write more once I identify what made it all flow, but let’s just say I’m hungry for more. Stay tuned.