Tom Dommett wrote in to share his positive experience with pair programming:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html
I have worked in pair-programming situations that have worked as well as those that haven’t.
When it works, it works very well. My best experience was working with someone who was about the same skill level, but who had been on the project much longer. It was always a very enjoyable and motivating situation, and we got a lot done and did it well.
But the times it just didn’t work were when I was paired with low-skill programmers who didn’t care. When they sat in the reviewers seat, they would sometimes even fall asleep! Pair-programming is worse than useless in that situation.
If you can find someone you can pair well with, it’s worth it. Do it.
As for code reviews, I haven’t ever seen them work well.
One factor you don’t mention, Jeff, is management buy in. If your organisation isn’t currently going in for pair programming, it’s very hard to convince management that it is a good idea. They can’t believe that it can do anything but halve productivity. Code reviews, on the other hand, is an easy sell. Another factor is geographical spread of the team.
I am a contractor, and so move around quite a bit. My last contract was in a London-based XP team, and so involved a lot of pair programming. My current one doesn’t, although I have now introduced a system of code reviews using Crucible. We have a geographically spread team of developers (four in London, two in Mumbai), and so in many ways code reviews work better for us than pair programming would. But I still miss certain aspects of the pair programming. I certainly code better when pairing than not. Sure, code reviews help pull up the standards as well, but to my mind not to the same extent.
Rick’s approach is interesting as well. Having looked at TeamCity recently, with its delayed commits, I wonder if a second pair of eyes could form part of such a delayed commit approach? Anyone know of any tools that allow for this (Mumbai is a long way to walk for a second pair of eyes …).
In my experience, “peer code review” does not result in all the bugs being caught. For any large code changes, I only see general comments in “peer code review”.
In my opinion, “pair programming” gives me a better bang for the buck! Having two engineers is better for the morale of the team, improves communication, provides real training and helps me do away with the paper work of a “peer code review” process.
There are some disadvantages of “pair programming”. They are not big enough for me to be worried about but some other people might find the information useful -
-
The day-to-day progress is slower than when a single programmer is working on the project. However the end result is a product of much higher quality so its worth it! In those organizations where each phase of the project has its own deadline, it is very difficult to introduce “pair programming”.
-
It requires great discipline and oversight to make sure that the “pair programming” routine is being followed. The strong programmers have a tendency to takeover the coding process while the weaker programmer would be happy to stay in the reviewer’s role without significantly contributing to the project.
One of the main problems I see with this (that you didn’t mention) is that the obvious conclusion to this is double the hours per project, at minimum (and I’d expect that you would work slower if you had to discuss or explain stuff to someone else the whole day). Double the hours puts a massive mountain for the advantages to climb out there. Is pair programming really that much better that it’s worth twice the money ?
Also, I personally don’t really like to talk a lot. I picked an office job in programming in part because it lets me spend most of my day in silence and concentration. Having to work that closely with someone else all day would certainly put a dent in job attractivity for me.
My first experience pair programming was sitting down with someone and figuring out how to script Active Directory actions. This was ~2001 or 2002 and we had a devil of a time working on it individually. MSs docs were not always helpful. The technology was still new to the IT department. What we did in one day would have take 3-5 days individually. For risky and experimental code, I believe pair programming can save a great deal of time. After that day, both of us knew the code inside and out including many of the variations that had proven not to work.
IMHO it might even be better on the days when you aren’t feeling up to much for your productivity/momentum to pair program - because you may not feel like doing a whole lot yourself, but you can usually get into it if someone else helps you stay interested.
I know it would help some days when I start to procrastinate and lose more time than I realise.
But then I’m in a case where I’m very isolated and don’t have much feedback other than a fortnightly dev session with the others in the group - and they don’t develop in my section and I rarely see their code.
We’ve discussed Code Reviews etc, but it always seems to be the same guys reviewing each others code because they feel each other know and understand the code best - and that doesn’t really help anyone learn or grow outside of those guys.
So yeah, the few times I’ve pair programmed I’ve learnt a lot and been a lot more motivated in what I was doing.
I can’t help wondering if pair programming is nothing more than code review on steroids.
The practice of pair programming was popularised via Extreme Programming, which has as part of its philosophy that “if a programming practice is known to be effective, take it to the extreme and do it as much as possible”. That philosophy applied to both “code reviews” and “collaborative code design” give the practice of pair programming. http://c2.com/xp/PairProgramming.html
But it’s a misconception to think that code review is the only benefit to be had from pair programming.
For pages discussing objections, see http://c2.com/cgi/wiki?PairProgrammingObjections http://c2.com/cgi/wiki?PairProgrammingQuestions http://c2.com/cgi/wiki?PairProgrammingDoubts http://www.c2.com/cgi/wiki?PairProgrammingMisconceptions
and for testimonials see http://www.c2.com/cgi/wiki?ProgrammingInPairsTestimonials .
Got to jump in again here. Can those of you claiming that pair programming is double the number of hours per project clarify whether you’ve ever worked in an established pair programming environment? My experience is that the overhead is far smaller than that because productivity stays higher - there’s less wandering off down blind alleys, losing focus, banging your head against a brick wall working out how to do something. As has been observed already, code quality is much higher, so there’s also less tidying up after the event.
Back at my old office there was nothing like a code review; the developers were like super-heroes and the development style hero-driven development.
Here, I sometimes get it reviewed by my team lead, VOLUNTARILY, because i think that at least he should know what was done for waht reason. He actually thinks that I am good enough not to make a mistake! Anyway, code reviews when wetried doing them went pretty well, but the overall impact of that on us was not that significant.
I find that “everyone doing everything” works great in combination with “guru watches the n00b” technique. It sure keeps the quality of the product up - but the core value for such approach is teaching developers new tricks. Everyone gets to learn C#, ASP, SQL, X-stuff, JS…
It’s easier to get up in the morning and go to work if you know you’ll learn something new today!
The most effective pair programming that I have done in my past is that once everyone has done what they can do alone, and they need help with a very complicated debugging, or a very tough problem, then for a few hours we would pair up and go at the problem together and even tag team other people into the programming sometimes too.
But the most difficult problems and debug sessions I’ve seen were multi day single sessions where someone only stopped to eat and sleep and they did it alone.
I am a big believer in code review after the fact because it forces everyone to explain to others on the team what they have done and why and to clean up the code. We also discovered a lot of errors in the code review that would have gotten put into production otherwise.
You can still do code reviews even with pair programming. It’s not an either or choice.
As the only developer in my shop, I don’t have the luxury of either, so instead I have an imaginary friend - she keeps me honest, and ensures I don’t do those short-cuts and hacks which might be quicker now, but will cause me pain down the line. Plus she’s really hot, which is always a bonus.
/ Might have been doing this too long 
For most simple programming problems, especially ones I’ve solved before, I think working with another person can be pretty inefficient.
But when working on particularly difficult problems, two heads are a lot better than one. If one approach doesn’t work, then you have another brain to suggest alternatives.
I’m not “against” pair/extreme programming. As Jeff mentioned, it’s not bad in small doses. But after 6 hours it begins to feel like you’re in the back seat in a long, long drive and you end up forgetting where you’re going. I think I’d just prefer code reviews over pair programming.
Speaking of code reviews, I was once in an hour long code review (more like a standards review) that had the sole argument of code formatting of class properties…
public String MyProperty
{
get
{
return _myProperty;
}
set
{
_myProperty = value;
}
}
verses…
public String MyProperty
{
get { return _myProperty; }
set { _myProperty = value; }
}
Yeah, that’s when I knew I wanted a new job.
I can see educational value of prolonged pair programming sessions. However, I find full-time pair programming counter-productive and damaging to software quality because the programmers will disrupt each others’ flow (http://en.wikipedia.org/wiki/Flow_%28psychology%29). So, in my view Code Reviews is a more suitable tool for improving quality of software.
I have some experence with pair programming I think it is important the 2 programmers are of a similar experience level and probably most importantly get on.
I remember when I first started as a programmer I was paired with someone with about 15 years experience so alot of the time he was explaining to me what or why he was doing something (and doing most of the typing). Perhaps the section of the program was a bit too complex for a relatively new programmer and it would have been better to pair me at that point with someone else relatively inexperienced on a simpler section so we would learn from each other not more of a one way street.
Still I am very grateful for what I did learn but I think if the programmers are at such different levels a code review is better as a newbie will probably read the code in their spare time to improve their skills.
I should have clarified: yes, the increased productivity is the advantage (obviously). However, to start out, you still pay two people for one programming job. Hence, double the cost. The question is, is the production increase really high enough (100%) to cover paying two programmers to do one programmers job ?
And no, I never tried anything like that, I’m just curious.
I would freak out if someone would watch me every the time I code (and also has a keyboard to interupt me lol)
On a previous job we introduced absolute and relative reviews.
Absolute review: an official code review, usually after very big changes or for new modules from scratch. Like a document cannot get status 1.0 without a review so can’t code.
Relative review: for small changes a developer only needs to have his code checked by one other developer before committing. So if you solve a bug with minor code changes, you ask a fellow dev to check your code. This developer should be absolutely convinced what you did is correct. If there is doubt, the architect is called.
Relative review is of course only possible on code that has had an absolute review. A task based CM also helps a lot for this.
Advantages:
- easier to introduce as pair programming
- dev cannot check in as easily at nine o’clock in the evening
- devs know each others code better
Disadvantages:
- slows devs down (but this is also an advantage, see above)
- ?
I’ve been in a few agile projects, but in my experience real agile (pair programming, user stories, …) is very difficult and very easy to fail. And when it fails it will be much slower and harder than with the traditional methods. And there is always someone willing to prove you wrong…
I’ve also noticed many customers were not fans of code reviews, but if they call it code reading, it’s usually a good indicator they are doing it wrong