Concluding an Experiment on Pair-Programming
Over the last eight days, my colleague, Maciej, and I conducted an experiment in pair-programming. The experiment was inspired by a terrific piece on pair-programming by a highly-respected Java guru, Elliott Rusty Harold. (You can find his article here.) I've done pair-programming in the past, but never rigorously and so wasn't sure whether my affinity for it was justified. Today we concluded the experiment and discussed what we thought of it.
Our schedule for the days of the experiment were...
8.30 - 9.30 : Free time. Read, do email, explore blogs -- whatever
9.30 - 12.30 : Pair-programming
12.30 - 2.00 : Free time
2.00 - 5.00 : Pair programming
The project we worked on was a large one and some parts were quite complex. We had a good understanding of the domain already.
During our pair-programming time, we worked on one computer with two 24" monitors. We traded off coding when one of us got tired or when one of us had a better understanding of that area of the application. We did not discuss whether we like the experience while our experiment was under way.
Maciej and I discussed our findings. While not scientific, the results were very valuable. Here are the points that emerged from our discussion.
1. We felt the quality of the code was higher than either of us working alone would have produced. Often, one of us would share knowledge the other didn't have (or wasn't as familiar with).
2. We felt the quantity of the code was larger than we would have produced working separately. This was the biggest surprise to me, as I thought there would be a trade-off here. I believe the reason for this is related to point no. 3.
3. The three-hour sessions were intense. When we were pair-programming, there were no breaks to check email, read blogs, and generally avoid unpleasant work. At the end of the sessions, we were tired and found the 90-minute lunch break very helpful in "resetting" our brains for the next session.
4. We found that working together helped us produce cleaner, better-structured code. This was perhaps due to the constant refactoring of code as, together, we found ways to restructure and streamline our code. Less-than-optimal code that would have slipped through, had we been working on our own, was fixed.
5. Our motivation stayed strong throughout the project. This is a key factor, often overlooked. Code is only as good as the mental state of the programmer who produces it. Those sessions were intense. They were also very invigorating.
6. We gained from having a shared understanding of the full scope of the application. I think this will prove very helpful during the extensive maintenance the nature of this application will require.
7. We met milestones sooner
8. Having definite times of intense work and scheduled down time made it much easier to avoid external distractions. I was able to tell people, "Please contact me between 8.30 and 9.30 or between 12.30 and 2.00" Something a little magical there about having a schedule.
We decided that we want to continue with pair-programming. Being that productive is very rewarding. We also decided that we definitely wanted/needed to continue those breaks. I'm very pleased that the experience was such a good one.
Very cool! I'm a bit jealous.
IMO, I think remote pair programming is just good because you are sharing the screen of the person who is doing the typing and you're basically looking over their shoulder. It's just as productive in either situation, but maybe others would prefer to be in the same setting.
@Sarah The free time seemed just about right. If anything, though, I think we could give even another hour away per day and still be ahead on the metrics of quantity. As for how long we can sustain the intensity level, that's a very good question. It may be that we'll try something like "free Friday afternoons" -- or maybe even let Maciej go home at 12.30. I think the "work hard, play hard" idea may be very effective, but I'll report back as we get more experience.
Remote pair programming is good -- but not, in my experience, nearly as good as being together physically. I think the key to this is an agreement that, while pair programming, both programmers' focus will be exclusively on that task.
Would you say that the skill level between you and Maciej was about equal? I can imagine that disparity of skill would challenge the effectiveness of the pairing.
@Matt re: varying the pairs...IMO, variety is always good, and since everyone tends to pick up on different things, working with different people will expose each other to those strengths.
Very interesting topic!
@Matt : Yes, I think changing the pairings is important. Hatem came down yesterday and we did a LONG day of pair programming. I was surprised that the experiences with Hatem and with Maciej were so similar, given that they're very different types of people. Interesting...
@Sarah : In the past, I've done pair programming with very junior developers -- and still found the experience good for both of us (and for the code). Even when a junior developer may not be able to add much in terms of code help, having someone to explain things to is VERY helpful in getting one's thinking straight.
Back in 2001, we did some experiments with pair duration (between swaps), which we wrote up in 2005 ("Promiscuous Pairing" paper. We found that, for us, the optimal pair duration was between 90 minutes and 2 hours. That kept us continually in beginner's mind, rapidly learning.
It also helped a lot with sustainability. We got up to working 5 90-minutes sessions per day, day in and day out, for 18 months. However, it only worked when there were at least 4 of us on the team (so we could rotate around enough).