I’ve noticed a lot of comments saying things like, “it’s nice for a while, but you can’t do it full-time every day” or “it works for the really hard problems, but not so well for day-to-day stuff.” So I guess the real question is how do you create an environment where you can do pair programming part of time, and work on just the things during that time that lend themselves to pair programming. How do you identify those items? From what I’ve heard, places tend to be either nearly full-time pair programming or pair programming only by accident, with almost no middle ground. Anyone have experience working in a shop that does does pair programming part-time?
I used to work for a fairly large software firm, where in theory we had to have code reviews by the group leader before check-in. In practice, only fresh hires’ code was checked for the first couple of weeks. The reason: the codebase for the software we worked on was very large, old and of low quality, so most of the changes we made were “not pretty”, and people didn’t want to look at other people’s unfortunate projects (“You have to add that feature? Ha! It can’t be done.”). At our particular group, an additional factor was that the group leader was an ass (“Let’s think in terms of complex solutions”), and asking his opinion about anything usually made matters worse (since then you had to do what he said).
There was a fairly experienced programmer on the team, so I would periodically ask him to review what I was doing (despite the looks the group leader gave us) and that really helped. He always had great insights due to his experience, and this is the way I learned the most. The guy I ended up quitting and went over to another company, where we still hold these discussions, now on more equal terms.
My understanding is that PP is seldom a whole-day activity. Nor, in some cases, are pairs static - I don’t know if they’re apocryphal, but there are stories of pairs switching once an hour, at the ding of a timer.
And it’s not just about code quality, spotting problems and the like: it also promotes broad knowledge of the code base throughout the team, which reduces the likelihood of duplication/deviation and increases the chance of highly cohesive and lowly coupled solutions.
I strongly suspect that, like many XP practices, it works best when applied with others. Small increments of development (stories), TDD and continuous integration would seem to be pretty essential for a successful long-term application of PP.
I live in hope that I may one day be able to find a job that lets me experience XP properly without needing to take a cut in my overly comfortable salary…
I think for the more complicated parts or “cutting edge” parts of a project pair programming can be great. For simpler, more run-of-the-mill software, it isn’t necessary and can be costly. I’ve found some personalities are not compatible with it.
I think pair programming is a great idea when used appropriately.
As with any good idea, it all goes wrong when a large project or company adopts it across the board and forces it in places where it is not appropriate. Yep, I’m a corporate monkey…
I think gunther is particularly on the mark here in suggesting that the people in question are going to make much of the difference. There are some people I know who you in fact COULDN’T pay me to work with—they’re either poor collaborators or are on such a different wavelength that there’s no point in us trying to see things eye-to-eye (I’m skeptical that there is a “universal language of code”—as with any language, there are lots of ways to say that you are skinning a cat, to pervert a phrase). However there are some collaborators with whom work would come quite naturally and easily.
And as usual of course I’m suspicious of anything that labels itself as one-size-fits-all. Perhaps its the fact that I have apparently a strangely-shaped body (it’s impossible to find pants that are my size, which isn’t extreme in any respects but must lie at the ends of a couple bell curves), but I’ve rarely found myself within the “all,” and I suspect there are a lot of other people who are quite similar.
Some of my best work has been sitting right beside someone and working through a project. Having another person there, especially at the start of a relatively complex project, 100% of the time really does increase productivity - that extra pair of eyes picks up small things (typos, mismatched brackets) which allows the driver to focus on the larger problem, as well as being another person to bounce ideas off to find any problems much faster and save you from a lot of dead ends. I recommend it fully.
This was an interesting read. Thanks!
My experience of pair-programming(not on a professional basis) is that I’m much less likely to put in a quick hack just to get something working right now because someone else is watching and bad code is embarrassing.
I am taking an intro to java programming class to fufill a requirement for school. The professor has us program in groups of three every class. One person drives and the other two pretty much dictate the code.
Although it feels like running with weighted shoes at times I have been able to quickly pickup some quick tips, shortcut keys and other little tricks that I would have never known about.
Also when I am back to programming all by myself it feels like I have removed the weights from my shoes. I can run that much faster after practicing with the weights.
I recently started at a pretty cool company who develop and sell Crucible - a pretty cool peer code review tool. We use this in conjunction with pair programming daily in our product team (another product with ~ 10 developers) and I gotta say that even though I’m new to the whole process I think it really works.
From my experience, pair programming is a great way to bring a new developer up to speed with the code base, amongst the other reasons already cited. We don’t pair on everything though - some tasks just aren’t suited to pairing (e.g. writing tech specs, some maintenance and bug fixing). We also found that pairing doesn’t work for small teams so well (depending on your product, of course) as you just can’t allocate enough resources to spiking new functionality.
The code reviews come in on top of the pair programming. When a pair is working on a piece of new functionality, our team lead will usually delegate someone to review their commits using Crucible on a regular basis (or once at the end, which I find doesn’t work as well). This allows the pair to get some much needed grounding, as spending too much time pairing can sometimes make you feel invincible and you might start to miss tiny things. However, when you combine pair programming + code reviews + continuous integration + a full test suite, you’re running a pretty tight ship!
If you want to check out Crucible, visit the site: http://www.atlassian.com/software/crucible/
Way back in 1989, I worked for a manager who decided pair programming was worth a shot. We did it for about a year and a half. I was surprised to find that it was nearly as time-efficient as solo-programming, mostly because we’d overcome obstacles faster. I have a tendency to want to really chew on a problem before asking for help. Sometimes, that ‘chewing’ transmutes into distraction - surfing the net, daydreaming, etc. In a paired environment, the moment a roadblock shows up is usually the moment the navigator says ‘here, let me drive’, and he takes a mighty swing at the problem.
I’m sure that interpersonal chemistry is a critical ingredient to successful pair programming. We were all lucky enough to be about the same skill level and more-or-less egoless. I’ve worked jobs with a few prima donnas on the team who I’m sure wouldn’t cope well with pair programming (though, if one paired two prima donnas together, they’d at least stop disrupting everybody else! 
At a later job, we were paired intentionally lopsided, so the old hands could mentor the noobs. I found the best way to work was for the noob to become a ‘voice-activated typewriter’. I’d dictate code, and anytime I did something curious, the noob would ask why and learning would ensue. I’d also frame problems we were about to code and ask the noob how he’d go about it. It wasn’t the fastest way to code, but having an audience did make me more fastidious, and I’m sure it was the fastest way to transmit coding craftsmanship. A good investment.
The one downside of pair-programming for me was the ceaseless nature of it. Just as Brooks points out a fivefold variation in programmer productivity, there is at least a fivefold variation in my own productivity from day to day. In a paired situation, the person who was more on the ball would usually drive, but there was still a nagging feeling that the less on-the-ball person should get with the program and he didn’t have the luxury to just stare at the screen all day. Good for the schedule, but hard on morale. Sometimes my partner and I would agree to take separate problems and go solo for a few days, just to get back into the groove.
On the whole though, I’d recommend pair programming, provided the chemistry works between the participants. I believe it produces higher quality code at about the same rate as solo programming, and it ensures a lot of cross-pollination in the team. It also helps members accept the chosen coding standards of the team, some of which may be foreign to their natural style.
Excellent report on how pairing was used at Silver Platter Software:
http://svn.arlim.org/arlo_papers/Promiscuous%20pairing/Agile%202005/paper.doc
I’ve done a bit of pair programming off and on at work here, and all I can say is that there is a lot of code that just plain doesn’t deserve it.
Anything complicated or interesting, where having a second person checking your work stopping you from staring at a screen for an hour figuring something out - it’s amazing. It’s awesome.
But for the boilerplate setters and getters and obvious implementations - seriously, the guy writing the code is bored enough already. The guy watching him goes back and forth between half asleep and “oh, you missed a semi-colon.”
The best process I’ve found is having a small team working on the project in the same room, programming on their own for the trivial implementation, and brainstorming or pair programming for any of the trickier parts of the code. There are a million times where you don’t really need someone watching you constantly, but you could use a “hey, quick check - in what order do I need to lock these objects so I don’t get a deadlock?” without having to wander down the hall to their office or wait on IM.
Now, that said, I think we need more overall code reviews here, just because it’s always better to have more people looking at your code (and to some degree, because I and my normal partner have similar weaknesses in our coding style and knowledge). But I can say that I can’t imagine continuous pair programming to be actually productive - in over half of the code it’s more like a union construction job - one guy working, one guy standing there leaning on a shovel.
I personally use almost exclusively code reviews rather than pair programming. The main reason I think is that management buy-in is almost a necessity for full-time pair programming. But I too have doubts about doing pair programming a full eight hours a day.
Both pair programming and code reviews can be ineffective if people just go through the motions. You know this has happened when you just get those ‘general’ comments and nothing specific.
As a senior developer I do a lot of reviews, and have been thinking lately about how to make them as effective as possible. It starts with believing in the benefits of reviews, but how you tackle the review also makes a big difference. I recently wrote an article that goes into more details:
http://www.basilv.com/psd/blog/2007/strategies-for-effective-code-reviews
Paired programming can be very effective with folks with the same skill level, unfortunately, the trend I see as companies adopt paired programming and Agile style development is the it tends to average the skill levels down. For example, were we to pair a level 2 developer with a level 5 developer, we see about a 3.5 skill level’s quality of work. This is obviously a big win for the 2 but not so much for the 5.
And as far as peer programming instead of code-reviews, I have not seen an implementation of paired programming that resulted in less system testing effort, and in fact have found the quality of the code to have dropped due to rubber stamping your buddy that “knowns what he is doing”
But if done right, I imagine it’s fine, my question is, whatever happened to teamwork and communication. Companies seem to go to these development methodologies to rectify the fact that they have terrible inter-group communication.
Just my $.02
Good article. From what I’ve observed, you have the balance between pair programming and peer review right. As I see it, pair programming is simply a special case (a particular style) of peer review. That doesn’t make pair programming better or worse than, say, formal inspection, just different.
Everyone has an opinion, but where’s the science? I haven’t followed the literature on peer review closely. It strikes me as a discipline that’s amenable to scientific method. Has anyone done rigorous experiments that show, under controlled conditions, which review techniques are the most effective?
Excellent overview of the two major approaches to getting more eyeballs on things. I’ve done a lot of code review at multiple companies and see it as invaluable (if sometimes tedious). I’ve done some pairing and while I like it, I wouldn’t want to do it all the time.
What I’m struggling with now is how to do either of these in a distributed team. I’m currently leading a team with people in four places and I myself have no one co-located.
We’ve started to experiment with code reviews and pairing over screen/app-sharing programs and so far it’s been just ok. Still learning. Any tips from anyone?
I think some sort of compromise is needed between these two positions. I can’t imagine coding with someone looking over my shoulder and making comments. Nor, can I imagine suddenly releasing my coding in the middle of a program and handing it to someone else. I’ve never tried that, so maybe it does work.
On the other hand, code reviews seem to take place after the damage is already done. Someone spent 24 hours coding, and by the time they finish, it’s too late to really do anything about it. As one person told me, code reviews are like a group of people looking over a deadly traffic accident and critiquing what the drivers should have done.
I think pairing developers is a great idea, and having them involve in overseeing code as it develops is a great idea, but tying down two very expensive resources at a single terminal is going to be a lot for management to swallow.
Maybe a compromise: Pair developers, have them discuss their tasks, and how they will manage their tasks at the beginning of the day. Then, at the end of the day, review each other’s code. It will take some firm scheduling (9am all developer pairs meet with their partners to go over their day’s activities. 4pm: all developer pairs meet and review each other’s work.) But, it will allow both developers to work separately while at the same time understand exactly what their partner is doing and how they plan on doing it. It would also allow the code review at the end to go a bit smoother since the partner will understand exactly what their co-developer was up to and why they wanted to do it that way.
Jminadeo you hit it on the head.
A lot of hipe to replace proper work habits, ethics and communication.
When you write poor code, you know it, do it right the first time, as you should. There is NO excuse for hack code, if you don’t have enough time to do it right the first time, what makes you think you will have enought time to fix it when your hack code breaks!
Get back to basics people, Proper Work Ethic, Good Solid Code, Communications, that will eliminate all of this foo-foo crap.
Do your work and be responsible for what you produce!
I admit that my 24 years of embedded programming experience have left me very cynical towards this idea. The first thing that bothers me is I have an introverted personality. Doing the job is far more important to me than talking about it. I can’t talk through what I’m doing! If it is a difficult project I depend a lot on refactoring - totally blow yesterday’s code away and start over. Having anyone looking over my shoulder would be very boring for them and it would slow me down to have to explain.
I worked at a place that was going to try this. They wanted to pair a junior programmer with a senior programmer (me) and have the junior programmer at the keyboard. This is a good way to teach but not a good way to get anything done!
If Management is involved in this process it becomes too cumbersome to use.