Programming has two modes: writing code and reading code. Pair programming has three: writing code, reading code, and explaining code. Explaining what code does makes you look at it differently than simply reading or writing it. When explaining code you are more likely to notice that what you think code does isn’t what it really does.
Pair programming, a technique whereby two developers, sitting side by side, work on the same piece code, is a key principle of agile development. Yet, it is also perhaps the least practiced one. For one, managers may have a difficult time accepting that two developers would be doing the job of one; and pair programming may also make some developers uncomfortable.
Far from being an expensive practice, writes Harold writes in his article, pair programming can yield almost immediate productivity benefits and, consequently, cost savings, for many reasons. One such reason is that pair programming combines code reviews with coding:
Code review is good, so continuous, instantaneous code review is great; and that’s exactly what pair programming delivers... feedback comes immediately. This means less time waiting for reviews and less time going down the wrong path. The time savings compared to classic code reviews is dramatic. In fact, this savings alone is likely to pay the cost of pair programming...
When presented with a 60 file change list, the tendency for most reviewers is either to give it a perfunctory once over, or to merely focus on the little details like indentation without really seeing the bigger picture.
Code reviews start and continue one line at a time and grow gradually with the code. It’s much easier to understand code this way than by having 60 classes and 3000 new lines of code dumped on you in one huge batch... The sooner the flaws are noticed, the cheaper they are to fix. Pair programming is much less likely to produce misguided code.
Another benefit of pair programming comes when developers with different skill sets, and even different skill levels, are paired:
Try to pair programmers with different skill sets and experience levels rather than similar ones. A pair is as strong as the strongest pair member, not as weak as the weakest. In fact, it’s probably stronger. The harder and more urgent the problem, the more critical it is to use pairing. If you have some really thorny problem, for instance involving multithreading, don’t pair your top experts in multithreaded optimization. Pair one expert with the lowest intern on the totem pole, so you grow more experts.
In addition, when two developers work together on the same problem, they are less likely to succumb to the distractions of the office environment:
Microsoft and Fog Creek give their programmers private, quiet, distraction-free offices. The rest of us work in cubicles where we have to listen to the web designer two cubicles over yell at Verizon for two days trying to get out of a cell phone contract. Noise is a real problem for many, many programmers. You just can’t think when your brain is in a blender. Your brain does not filter out conversations happening around you...
This is where pair programming really does seem like magic. Your brain has evolved to focus preferentially on a nearby conversation instead of a distant one. When you are focusing on the person next to you, your brain masks out all other conversations at any volume below a shout. The interaction between the pair is so high-intensity that low intensity noise from a cubicle environment is much less problematic for a pair than for a programmer working alone...
The eight hour day is a myth. Between meetings, lunch, e-mail, water cooler chatter, personal errands, paperwork, birthday celebrations, collections for going away presents, and more, you’re lucky to get two hours a day of solid coding time. Four hours is great. And even if you have four actual hours to sit in front of the keyboard, how much of that is going to be wasted on e-mail and the Web?
When pairing, programmers actually program. They don’t check e-mail, read blogs, play Scrabulous, and generally goof off. If they have to check a web page to look up the exact behavior of a class (which they’re less likely to do in the first place because one of them may know the answer even if the other doesn’t) they come right back to the IDE after finding the answer. Four hours spent pairing is much closer to an actual four hours spent coding.
In your experience, does pair programming live up to the benefits Harold espouses?
And what do you think of Harold's statement that "you’re lucky to get two hours a day of solid coding time?" Do you agree that typical workplace environments and programmer habits (reading email, browsing the Web, and so on) result in such few actual hours worked?
I think that the 2 hour figure is probably more accurate than what most people (managers and programmers alike) would like to believe.
In my experience, there is an incredible amount of distraction in the average working environment, including phones, email, instant messaging, conversations between other developers, a dba loudly cursing a developer for blocking the production database for 5 minutes...
You might end up with 8 half-hours of coding time, but with the time to re-focus on the task at hand, that wouldn't really be any more productive than 2 solid hours in one block.
Places vary of course. I've been in places where at time I was lucky to do 2 hours per week. Other places, for instance if developers don't communicate, let me get a lot more productive time in. Of course, non-communicating development teams have their own problems.
Getting away from big office areas into small rooms with at most 4 people can be a big productivity boost, as the likelihood of external interruptions seems to rise exponentially with the number of people in the room.
While I expect that some people would be better able to focus while in a close conversation (pair programming), I find that for myself, even during a conversation, I still get distracted very much by other conversations around me.
So while pair programming would help some people get a lot more in-focus time, it would also raise the general noise level in the room, and could distract other people even more than before.
I think the whole agile thing (including pair programming) is a philosophy (not science). And you have to be careful when applying a philosophy to reality, because in reality it is always: it depends! Sometimes if you have the right people for pair programming then it might work well. But what if you have a solitary superprogrammer? You force him to make pair programming, he is dissatisfied and at the end he leaves the company. That might happen. And that means you started with great philosophical ideas and didn't consider reality and it struck back..
In my experience, pair programming doesn't work as well as a lot of articles claim and that code reviews are a more efficient way to produce high quality code.
The main problem is that pair programming requires a strong coupling between two developers, while the coupling with code reviews is much looser and much more flexible.
There are also a lot of human factors that get in the way of pair programming that are unfortunately never mentioned, or often glossed over, in articles that advocate its practice.
For example, you need the two developers to be in the same mood, in the same "zone", have compatible programming speeds and habits ("think first then code"? "code, try, iterate?", "write tests first? last?"), have similar personalities and abilities to listen and not react adversely to verbal criticism. Even practical details matter, such as the type of keyboard ("Control key at the bottom left of the keyboard? Are you serious?") and even use the same keybindings, window layouts or even shell aliases.
These all seem like details, but they matter when you effectively pair program, and the time it takes to work around them adds up very quickly.
I find that code reviews have the same benefits as pair programming (high code quality, spreading the surface of code knowledge across more than one person) but suffers from hardly any of these problems. Developers code at their own pace, on their own schedule and code reviews happen when they feel ready to present a version of their code to the rest of the world and, more importantly, when they are ready to discuss it.
Infrastructure and tools matter a lot too. The p4/svn way of doing code reviews has proven to be very effective, but I think that asynchronous reviews can be even more powerful when used responsibly: send the code for review and submit it at the same time, but you will have to address the comments from your reviewers when they come in.
Another new aspect that recently made its way into my daily developer life is that git has tremendously increased my ability to multitask. I've always found the client juggling (or patching) that g4 requires a big bump in my productivity, but with git, I find myself routinely handling and switching between 3-4 completely different change lists within seconds. This puts the value of code reviews even further ahead of pair programming in my opinion.
And of course, there is the opportunity cost of pair programming: sure, you produce code of high quality, but you might have been able to produce twice as much code of equal quality if you had let developers Joe and Anne work in their corners and then send each other code reviews.
> > And of course, there is the opportunity cost of pair > programming: sure, you produce code of high quality, but > you might have been able to produce twice as much code of > equal quality if you had let developers Joe and Anne work > in their corners and then send each other code reviews.
In my (limited) experience, pair programming results in far more than double return of tasks performed (lines of code are a horrible metric) mostly because of the some of the reasons mentioned in the original article (less opportunity to goof, less time spent on bug fixing, etc...).
Having said that, pair programming in general does not work - programmers are (generally) asocial creatures and don't work together well.
> ... > > Infrastructure and tools matter a lot too. The p4/svn way > of doing code reviews has proven to be very effective, but > I think that asynchronous reviews can be even more > powerful when used responsibly: send the code for review > and submit it at the same time, but you will have to > address the comments from your reviewers when they come > in. > > ...
What's "the perforce/subversion way of doing code reviews"?
> - programmers are (generally) asocial creatures and > don't work together well.
Hey, hey, you get offa my cloud. Has even more meaning today than 40 years ago. But this is the main reason it won't work. Even in "real" writing, multiple authors are based on master/servant relationship. "We" don't do servant all that well.
> Having said that, pair programming in general does not > work - programmers are (generally) asocial creatures and > don't work together well.
In my admittedly limited experience doing pair programming, I never had this issue. Yes, someone has to "drive" the process, just because that person's sitting at the keyboard. But that's not an issue of control. I would liken the experience to two people driving to some (possibly unfamiliar) destination in the same car - one of them has to do the driving, but both would ideally discuss the route, turns, etc.
Also, I don't see that inability to work with others is a typical attribute of programmers. I would never hire a person who can't work well with others, regardless of that person's individual skill level or position. Who wants to create unnecessary stress in the workplace?
I think the point is to do pair programming a couple of hours a day, ideally - it doesn't mean we then can't go back and write code individually after that.
> Also, I don't see that inability to work with others is a > typical attribute of programmers. I would never hire a > person who can't work well with others, regardless of that > person's individual skill level or position. Who wants to > create unnecessary stress in the workplace?
By inability to work with others, I do not mean inability to maintain good relationship with the coworkers and communicate ideas. That is important for most professionals - programmers or not.
Working together on a single piece of code at the same time is a completely different issue.
I agree with Nemanja. I don't consider myself asocial, but regarding heads-down coding I think clearer in isolation. My implementation may or many not be optimal, but (from experience) I don't trust that I have a clear runway to express my thoughts in a pair; too many interruptions. In the best of worlds my *design* is peer reviewed.
To be fair I think there are times when peer programming works best. Mostly it involves exploratory work; not so much writing code as it is learning something new.
Previous Topic
