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.
This is really a response to your first post on not “..believ(ing) in Pair Programming”. There seem to be two general groups on the issue of pairing; one that likes it and derives benefit from it, and the other that doesn’t. I think I understand each group. To say that that says anything about the practice seems odd.
In our shop, we don’t “force” the practice, in the conventional sense, but it’s strongly encouraged and more importantly, supported. It does take a while to get used to it and we give folks a huge opportunity to ease into to and adopt it.
What I can say after many years of personal ‘exposure’ to this practice is, that it does what it promises: it produces better code, it keeps developers thinking in a way that they can’t and don’t on their own and it produces it’s own rhythm in time. It’s exactly that rhythm, or “flow” that you describe, that keeps my folks coming back to it. They would tell you that it makes development more fun and they feel more motivated to create.
I’m always sorry when I can’t figure out a way to help individual contributors in my shop get there; they eventually move on to other environments where they can experience the flow in their own way. But I understand.
There are, of course, lots of times during the day when certain tasks are so mundane, that pairing would interrupt individual flow; we also encourage that.
I would like to hear more about your IM journaling. We use IM extensively in our shop; it’s on constantly, even for folks across the room. Whenever there has been a problem of miss-communication, it is always an IM (or email) issue. I guess I come down on the verbal, face to face side every time, but I may be old-fashioned here.
I think I get what you’re saying: you are in a distributed environment, and that means distributed communication. I don’t do distributed environments, exactly for all the reasons that you’ve come up with ‘solutions’ for, but if I had to do distributed, I think I’d be using the techniques that you’ve come up with.
Every team in our shop [save 1 out of 6], is co-located. The last has a single member [he's new and hasn't shown up yet, so this is an experiment] that will be working in another location from the rest of the team, 1/2 of the week. During the 1/2 week, he will be paired as much as possible with another member of the team, just so he’ll have support.
That’s the way we roll.
Hal