Distributed Pear Programming – Reprise
You may recall that I have come out in this forum against the traditional XP practice known as Pair Programming (http://marcatopartners.com/2009/09/23/spoiler-alert-im-not-sure-i-believe-in-pair-programming/) – while my fundamental objections to some of the specific parts of the practice stand, I also wanted to tell you about a much more successful experience I have had of late that might seem like Pair Programming. Perhaps together we can figure out what is working, why it is so productive, and what I have learned that you might be able to copy in your own worklife. Since I’m not sure what this is or what to call it, for the sake of discussion, let’s just refer to it as “Pear Programming”.
Conservatory at Como Zoo
First, let me explain the situation – I was working with a VERY distributed team; I’m in Minneapolis, MN, we had a product owner and developer in Denver, CO, another developer in Houston, TX, and a team of 3 developers and a tester in Minsk, Belarus. The very nature of our physical reality forced us to depend on the “virtual lifestyle” – I used Skype IM and voice and GoToMeeting constantly throughout the day to stay in touch with my team mates. On most days I start at home because that helps increase the overlap I get with the team in Belarus, but I would often transition later in the day to the office or some other location and would work anywhere with bandwidth, a headset, and enough privacy that I would not be bothering others.
I also assumed development responsibility for a portion of the project (yeah, yeah – I know – I’ll save the topic of balancing scrummaster and coding responsibilities for another day) and started working on a new application with a UI and Windows service and with a significant interface to a collection of web services being developed by my team mate in Houston.
As you might expect, our initial efforts were isolated, but after we each had established the basic functionality of our respective pieces, the effort shifted to integration. Now, there were a lot of technical challenges to overcome, not the least of which was my lack of familiarity with the object persistence framework and data access layer of choice, but the one thing that went remarkably well (and inspired this post) was how we communicated.
Goose Tricks
Both of us were working very hard and it was not unusual for one or the other to be online any time between the hours of 6 am and midnight. We came to rely on IM for quick questions throughout the day, but we also discovered that it had a different use as a record of sorts for the design discussions we had had, either together or one-sided. We started using it like a journal to record the thoughts and decisions we had made whether the other person was there or not. This “thinking out loud but in writing” was informal but very effective – when the other person did rejoin they could get quickly up to speed, provide advice or counterpoint if needed, but easily resume where they had left off with a far better understanding of what had changed since the last merge than one can garner from check in comments.
My take away from the experience is that while I would not universalize pair programming as a necessary practice, there are times where it just sort of happens naturally and when it does, it’s great. I’ve also seen that when it doesn’t work, it’s mutually frustrating for everybody as they try to force it. I also learned that an IM “journal” can be a better way of communicating than verbal – my arguments were better expressed and there was a record of thoughts had and decisions made that often escapes you in a verbal exchange. Bottom line – it was a VERY healthy and productive partnership and I dynamic that I still miss even though I have had other successful projects since.
