Agile Pair Programming should be amended.
Agile Development has taken the Ruby community by storm. It has been engrained into every corner of the community. However, many take the components as rules instead of guidelines which I feel is very detrimental to overall development speed. The component which speaks most to me as being a guideline is the idea of pair programming.
I feel that pair programming is an essential tool for developers and should be practiced in every business that adopts the agile mantra. The idea is not a new one either, it has roots to the saying that “two heads are better than one.” However, I feel that the commonly accepted practice of pair programming is what should be adjusted and improved upon. The practice I am talking about is that two programmers should work in a pair every day, all day on the same task using one computer.
The first problem with this is that in any business, dedicating two resources to solve a single problem is not always the most cost-effective practice. If the problem is easily solvable, having two resources solving the problem is like using 8 bullets when 1 would do the job, its overkill plain and simple. Now what if the problem is of average difficultly and you dedicate your two brightest minds to that same task? Well from my experience is that one will end up ‘driving’ and the other will fight to maintain concentration because their mind does not really need to be fully applied to the task at hand. This is again, a waste of resources. The only scenario where this practice works at an acceptable level from a business perspective is when you have two equally talented people working on a challenging task. Given that most development is spent outside this limited scope, I feel that this practice should be revised.
I will explain with a scenario: Given story X, two people decide to tackle the problem together. They decide what component each will work on, and sit on computers next to each other and set to work. These components hopefully have to interface together at some point, and both should be working within the same SCM branch. They continue to do TDD on their respective components, but along the way they are forced to work together to make sure that they are working toward the same common goal, which is meeting the story requirements. Asking the person if they are going to be returning json, scripts, or html to their interface and other related questions. Allowing both people to work together but exercise their creativity and influence onto their component, but still communicating/discussing implementation choices.
I feel that this scenario meets a broader target and allows for interruptions to happen without sacrificing the pair. In addition, it handles the case that both developers are both equally competent on the subject so that one mind is not wasted while one drives. People will argue that when this happens that one of them is being a bad pair and I will agree with you on that, but the problem happens to good pairs when one of them had an ‘off day’, etc (see: 21 Ways to Hate Pair Programming). Another problem is accountability of ‘pairs’. If two people are working together on a component, it becomes much easier to weed out the ‘weaker pair’ to either replace or work with on improving.
I am interested in hearing from the Ruby, Rails, & Merb communities about this approach and what their feelings are about using it within their business. This is by no means perfect, but its just trying to illustrate that pair programming may end up being something like communism is, “Good on paper, Bad when applied.”
Update – Some have said that this is just not a pair programming revision, but more of doing away with pair programming. I did not mean it to come out this way. I agree with common pairing techniques when the scenario is warranted for it, however I feel that the majority of scenarios do not. Also working with 2 computers on 2 different components of a story would work given the right scenario (a story that is over basic tasks, or is multi-dimensional) I described above. Teaching and Challenging stories still benefit from current pairing techniques.
January 26th, 2009 at 6:06 pm
Hi! Thanks for the link.
Regarding the two-resources thing, I have two answers. First, as a friend puts it, “you get third-draft code in first-draft time.” As with unit tests, I feel like pairing brings up the quality of my code, meaning the extra man-hours put into pairing pay back in reduced man-hours debugging and code that’s easier for others to work on and with.
Second, if you’re working on a problem that’s easy/boring, that’s often a sign you should be working at a higher level of abstraction. Computers are good at repetitive and/or boring work, and people are good at the hard thinking, so it makes sense to make the computer do the easy parts. That’s especially true in languages like Ruby, which provide so many opportunities to take things up a level.
I also worry that you are undervaluing the knowledge sharing aspect of pairing. If people switch partners every few hours, then that means every bit of code gets a lot of eyeballs on it early. Not only does that mean it will be more polished, but it means there will be plenty of people willing to work on it later. On a team that does promiscuous pairing, people can actually take real vacations, ones where they don’t talk to anybody in the office for weeks.
That’s not to say I pair all the time. For code that’s meant to be thrown away, I don’t think it’s worth it. Ditto for code where I’m just kicking an idea around; when I’m just experimenting, sometimes I’d rather do it alone. But when I set down to write code that matters, I’d always rather have a pair.
January 26th, 2009 at 6:48 pm
Yes but if you are skilled enough to write quality tests, than the second set of eyes is your CI box and than your QA person. Usually is enough for me. If something is difficult tho, a think-tank is usually a good idea.
January 27th, 2009 at 12:29 am
Yes but how do you know your tests are of high enough quality with out a second set of eyes to confirm it? The measure of quality tests is not that they are green and pass CI but that they appropriately exercise the assumptions and requirements about the feature you are implementing. Tests don’t account for a bug in an assumption or a requirement.
Also, CI doesn’t count as a second set of eyes it just makes sure you ran all the tests before you do a build.
February 22nd, 2009 at 3:03 am
I think Gabe and William have hit several points right on the head.
We’ve dabbled in pairing on my current project for some situations, and I certainly think that it’s a valuable tool. There have been a lot of mistakes I’ve made that would have likely not have happened with a pair because I would have given more thought to what I was doing instead of just chugging along on autopilot. Same with a lot of tasks that I held off pairing on because I thought they were just grunt work and didn’t want to waste my pair’s time. In retrospect, they probably could/would have been done in a more efficient way since I would have been forced to think smarter. There’s a quote (think it’s from Jay Fields, can’t remember right now) that’s something along the lines of “If it hurts, you’re doing it wrong”, and i think disciplined pair work definitely helps prevent you from brute forcing just because it’s easy to start.
That having been said, I don’t think it would have worked out for us to do pairing 100% of the time. Our timeline is too compressed to spare the extra time required for full-time pair work to ramp up to a good level, and being able to divide and conquer for UI vs. backend has helped a ton with being able to get the project out the door. There’s definitely been a tradeoff in quality in that I spend more time fixing bugs after the fact and my tests probably aren’t as comprehensive as they would be ideally. In this situation, I think we made the right decision – the extra time we’ve spent fixing bugs has been less than I would estimate we’d have spend doing pairing full-time and has been the key in letting us deliver on time. It’s also thrown the ‘work at a sustainable pace’ tenet of agile/XP out the window. I don’t pretend that either of these is the case for any other project, it’s just how things have worked for this one in particular.
The other piece I think is key is promiscuous pairing. If you’re pairing with the same person all the time, it’s easy to fall into the same sort of autopilot mode you get into on your own and the benefits of having another set of eyes are somewhat diminished. It’s when you’re switching off more often that you break the sense of individual ownership and get consistently fresh perspectives on the code and what may/may not be working.
I’ll leave with another interesting article on the topic from the folks at Pivotal about the percentage of time they spend pairing (http://pivotallabs.com/users/joe/blog/articles/698-pair-programming-solo-futzing). Whether or not you agree with the percentages, the breakdown of which tasks go into which bucket make a lot of sense, at least to me.