People often ask how can I justify two people when one will do. Will this not, just double my cost? To answer this question I think it is important to discuss what pair-programing is not.
How much of your time do you spend writing code? If you answer 100% than you are lying! Between checking your emails, going to meetings, talking to people, mentoring others, finding bugs and thinking about fixing them, coding is something we do surprisingly little of. I only do coding about 10% of time, but i am probably at an extrema, so lets say you code 25% of time. Even when you are coding, you spend a lot of time testing what you have just coded, and realizing what you have just done does not work. Your end product may be 100 lines of code, but it may take you weeks to get there.
Out of 25% of coding how much do I pair? Not enough, but lets say 25% of the time. Overall you are only talking about little over 10% of my overall time I am pairing which you can say that I only cost 10% more (if you can apply accounting logic to coding). But what does this extra 10% of “cost” buy me?
At most places I have been at when a new developer shows up, they hand him a computer and say, “OK, get up-to speed and build this feature X.” Then most places do not expect anything out of the developer for few months while he “gets-up-to-speed.” Few months? I expect my developers to check in a feature the first week! But you can’t just demand it you have to approach it differently.
Let me tell you about Arthur, the last developer which joined us for a month, and how productive he was. Arthur showed up on Monday at 9am. I sat down with him behind his computer and said, “Let’s get you up-to-speed.” I made sure that he was driving, and I was talking and we started installing all of the software which he needed to develop code. The compilers, the database the IDE, checking out the code from the repository and running it. The key here is that Arthur was doing all of the work and I was just telling him what to do. By noon, he was up and running, thanks to a very intensive hand-holding from me. We went to lunch and talked about the application, not in general terms but in specific terms which Arthur could translate to what he did few minutes ego.
After lunch, I said let’s go and fix a bug. I picked a simple bug and for the most part again i was doing most of the talking but made sure that Arthur had the keyboard and understood what, and why he was doing things. By 3 pm we had a fix. We ran all of the tests, and submitted the code. We watched the build to make sure we did not break anything.
This is pairing, and it is exhausting! By 3 pm I was beat and went home, but Arthur stayed to play some more with the code. Turns out he fixed another bug on his own before he went home. Not bad for first day. Now I could have fixed the bugs myself in 1 hour flat both of them, but then Arthur would not learn anything. I sacrificed my productivity to make Arthur productive in a single day. If I did not it would take Arthur weeks before he would figure out how to set everything up how things worked and enough courage to fix a bug. Yet that is exactly what most companies do. Think about the confidence Arthur had on day one working with us. He was up and ready and he fixed two bugs on day one. WOW!
More importantly is what we did not do. We did not get distracted by checking email. How can you, you have a single monitor, and that means that Arthur would read my email. Arthur did not waste time looking for documentation which is poor or does not exist, he was spoon fed the knowledge in the most efficient way, and he did it all by himself, i was just talking, he was typing. It is amazing how much more focused you are when you have two people working on something.
Next day, we paired some more, but this time we started to build a new feature. Again I was taking Arthur through the implementation making sure that he did all of the work. By the end of the week Arthur has implemented several features and the amount of pairing we did has dropped of significantly, but instead Arthur started pairing with other engineers which had the know how which he needed to get the features done.
At the simplest level pairing is helping people one-on-one, not through emails, let me show you behind a keyboard, instead of telling you in abstract. The amount of pairing and keeping each other on track depends on many things, but you will find that more you pair the more you will learn from each other and the better the code becomes.
But Arthur was a new engineer coming up-to speed, what about existing engineers? Well let me tell you story of Pepper the senior tech lead on a project. Pepper came to me and said, Misko, I don’t like the way we deal with X in our app, what could we do to make it better. Now here is a case where Pepper has all of the know how of his app, and I know next to nothing. So we sat behind the code and I started writing what I would imagine an ideal app would look like, knowing very little about the code. Pepper had to explain why my view was wrong or too simplistic and in the process we would learn from each other and slowly converged on an ideal design, which was neither his nor my idea wholly but a collaboration of our ideas. We started refactoring, sometimes I would drive and sometimes he would. We would take turns painting ourselves in the corner and then backing out. Many times Pepper would work without me, as the refactoring was tedious, but straight forward and two of us were not needed. All together it took us 2 weeks to finish this refactoring. Pepper did the lions share of the work, but we spent about 3 full days behind a single computer together. That is what is pairing.
If you would ask Pepper, he would tell you that pairing helped him focus. He would say that without the pair he would not have had many of the ideas which we ended up having. Most importantly there are now two people which really understand the details of the design. When I or Pepper will pair with someone else, we will share these new ideas with the new developers. As team pairs with each other ideas and knowledge multiply and flow making sure that the code-base remains consistent no matter which place you look. It is as if a single person has written it. This is a great thing which helps with maintenance.
Pairing does not mean that two people always do everything together and checking each others work, that would be boring and a waste of time. Pairing means that people bonce ideas from each other and have discussions, not in abstract, but behind a keyboard, keep each other focused and on track. Result of which is code which is better than the sum of its parts. Pairing is about sharing the knowledge with your team mates so that everyone is on the same page. We will go further if we make sure that all of us pull in the same direction, something which is rare in the industry at large.
37 responses so far ↓
100% agree with your last paragraph. I have found all the same advantages to pairing. Shame the idea of it still freaks out a lot of PMs.
Great argument for pair-programming or peer-reviews in general. If there is one quick win that improves the quality more than any other it’s reviews. In one of the companies that I used to work for reviews worked so well that we instituted a rubber-ducky reviews if there was no time for pairing. The idea was to explain your code to a rubber duck on your CRT screen before any check-in. It wasn’t as effective as pair-programming but it still caught quite a few logical errors and forced us to evaluate every piece of code carefully before it was checked in.
Real researchers have measured the effect of pair programming. It is as effecient as 1.25 programmers versus 2 programmers programming alone. That’s a loss of .75 programmers productivity for some quality metrics you might never be able to measure.
Maybe if bloggers bothered to google anything they wouldn’t have to rely on rhetoric, they could use evidence instead.
We just hired a new guy. For the firt week I let him look over my shoulder as he did not have a computer. Maybe I should have let him drive.
When the new guy’s computer came in, I sent him to another site and told him to get busy. I send him an e-mail once in a while. I bet he would benefit from some pair programming. But who has the time?
@Jim,
Real research?, By people who never really done it? Look, I am not talking about research, I am talking about personal experiences! You can ask anyone on my team and they will tell you the same. They are more productive, they love it, and the code is way better. That is good enough research for me. Pairing is just a fancy name for helping people.
Pair programming enables new-hires to check in working code on their first day.At my place, when we interview, one of the final steps of the interview process is to pair program with one of us for a few hours. We do not give the candidate an artificial task to code, but instead pluck a real user story off our project to-do list. The candidate and their pair work together for most of an afternoon. The candidate does most of the driving. This almost always results in a check-in that becomes part of our robust and high-quality product.
@Maintenance Man,
“But who has the time?” That is the crux of the question. In short run no one. But in long run with constant pairing I can turn average programmer into great programmer. I can make sure that the average guy understands the code and contributes to it in the spirit of it, as opposed to hacking. And how much is that worth? In short term pairing never makes sense, but we should not be here for the short term.
@Jim, miskoI think it’s a fair reservation to suggest that sometimes, NOT pairing will get you to a ‘finished’ state quicker than pairing.The problem is, that in real-world projects, with messy, complex and changing requirements (eg. outside usual research or university environments), getting to ‘finished’ is only half the job.Yes, 20 fingers type faster than ten-with-an-advisor. But which way of working makes fewest mistakes?The mistakes we programmers make are manifold. They vary from tiny typos, easily found and fixed; subtle bugs that might take days to find; design flaws which might take days or weeks of re-work; through to severe misunderstandings of specification which can, and often do, cause whole projects to fail.When a programmer calls a chunk of code ‘finished’, it is often *after* that point that the more significant of the above errors start to come to light.The productivity gains that I find pairing brings result from almost never having to go back and debug, or rework. Every single day we spend 95% of our time designing and coding new functionality in pairs, non-stop, day in, day out, churning out quality code.We might have been typing faster at my old employers, where paiding didn’t happen. But we were wasting 75% of our time writing rubbish code that then needed to be revisited later in the project.
You lost me with your maths at the beginning. If you really think people only program 25% of the time then perhaps another career would be better suited to you. If you think that 25% of 25% is just over 10%, pick something where maths is not required.
Your two examples illustrate mentoring, not pairing.When the two programmers have about the same level of competence, pairing will result in a net loss in productivity, as somebody already pointed out. You are basically producing half of the work that you could have done by having both programmers do their work on their own and then submit it for a code review.
Thanks, Misko… this is very interesting. I always thought pair programming was the boring “two people always do everything together and checking each others work” you mentioned. Your variant sounds much better – I will have to try it.
@Steve KosThe net loss in productivity is only valid if you assume that pairing produces the same code that not pairing would have done.In fact, pairing produces code that is of much higher quality. Although it might have been typed at 50% of the speed of two separate programmers, this apparent loss of productivity is (in my experience) more than made up for by the increase in quality and knowledge across the project. Fewer bugs, fewer mistakes and misunderstandings.
@Steve Kos again
Pair programming, in my experience, works better than code reviews.
Obviously, I’ve always been a supporter of code reviews. I have always supported their use. They bring great benefits. But compared to my recent experiences of pairing, code reviews are nowhere near as good.BTW: I’d love to hear from people who have experiences different from the following. For the record though, my experiences are:(1) Code reviews require a lengthy feedback cycle. Getting back to someone a day or two after some code is written is far too late. The original author has already moved on from the code being reviewed. They have started to write other modules, that may depend on or interact with the code under review. Changing the code under review now will have a knock-on effect on this work. The feedback should have come much earlier. Presumably code reviews every hour or half day could help to fix this somewhat (Has anyone heard of anyone who has tried this?) However, even hourly reviews is nowhere near as valuable as the minute-to-minute feedback conversation that comes from pairing. (2) Code reviews are intrinsically confrontational. The code author has an emotional investment in defending their completed code. They have a natural emotional response to overcome when a reviewer is telling them that their code is bad. This hinders a detailed, objective critical review process. Pairing, on the other hand, transforms the confrontation into a positive, collaborative creative process.
(3) Code reviews are hard to do well. Doing a good job at code review means generating more work for your peers. They will have a natural human reaction to this, and will dislike you for being a stickler, and will dislike doing the ‘needless’ rework. As a result, most people will not perform thorough reviews. They will skimp on the review, rather than pay the social costs of insisting that problems get fixed. These real psychological disincentives to doing good reviews mean that reviews are mostly just lip-service, even with the best will and work-ethic in the world. Pairing, on the other hand, avoids the rework by spotting and correcting mistakes before they get made.(4) Code reviews are very boring. To do code reviews properly, a significant number of hours need to be allocated each week to review each other’s code. This became a dreaded and unenjoyable part of my week. I believe others feel the same, and as a result they skimped on doing decent reviews. In contrast, pair programming is a highly sociable and fun activity.Like I say, I’d be delighted to hear from people who have had really good experiences with code reviews that appears to contradict these impressions of mine.Thanks all.
Nice post. —I’ve found pair-programming invaluable in bringing new team members up to speed with “how we do things around here”. This means giving them fast crash course around the code, the ANT targets, the servers, Trac, etc. I am not sure if I’d give this practice a fancy name, but essentially its about making a team member productive asap — good business sense.—Most of my work has been with remote teams, so we didn’t have the luxury of someone “looking over the shoulder”. We would often collaborate over an IRC channel and announce some function/functionality we needed… usually just a simple function. Anyone who felt like taking the task up would solidify the requirements of the function.We found that this improved our quality tremendously because the programmer would do the “most obvious” implementation. This allowed our functions to be simple easy-to-use black boxes. Anytime we had to make exceptions indicated a possible flaw in our design.
What Pair-Programing is Not « Netcrema - creme de la social news via digg + delicious + stumpleupon + reddit // Jun 13, 2009 at 12:41 pm
[...] What Pair-Programing is Notmisko.hevery.com [...]
Misko,1) So pair programming is not checking emails — got it!:-)This article did not really explain what pair programming is not.2) I agree with all the benefits of pair programming mentioned here: significantly speeding up learning, ideas exchange, immediate code review, focus on the task.Pair programming is especially effective for more complex tasks, when it’s not clear how to approach the problem.You are right that pair programming make sense only sometimes. Other times it’s better to work alone, especially on routine tasks.3) Please replace “than” with “then”.
The naysayers are hilarious. Pair programming is a tool, just like the other pile of tools we have like testing, consistent code styles, ORMs, IDEs etc. There are times when a tool is appropriate, and times when it simply wastes everyones time.The fascinating part about the article is not “pair programming is yay”, but that the examples provided are precisely the kind of situations when the tool is most useful – when you have a highly asymmetric knowledge level or when you have a very speculative goal. In both of these cases the objective is not Lines of Code, but Net Increase in Knowledge.Pair programming is not competing against two programmers alone, it’s competing against one programmer reading documentation or two programmers trying to outline a design on a whiteboard. In any situation where two programmers could independently get on with their jobs with an effective level of knowledge, there is no need for pair programming (that’s almost a tautology).That’s why it’s often the case that in Pair programming, the one who knows the least is the one who is driving – you’d get more code if the one who had more experience was driving, but you’d fail to effectively transfer that knowledge.
This isn’t “Pair Programming” per se, this is just healthy collaboration in a well functioning team. Good teams have been doing this since ages. The big difference between “Pair Programming” the recent “phenomenon” and just plain old healthy collaboration is ..well, Pair Programming is hyped up and is done full time, not on demand.The new hire orientation process described here is just common sense. The “find some sounding board when you need to think deep” and “find some sounding board when you are stuck” approach is also just common sense. The “have all code, specially tricky code, go thru a review process, and better if the review is done before the code gets checked” is also old, and common sense.But “Pair Programming” advocates this approach seemingly in exclusion of other approaches. There are times when being alone when thinking deeply is better. There are times when going out the building and looking far into the wide open is effective in overcoming a mental block.
A great read, Misko. You put a name to a concept I had not put a name to: pairing. I’ve trained a handful of fellow employees by pairing for a few days. The end result is a peer that I can almost immediately share insights with. I was unsure how effective this method was, but your post has been a real encouragement to me. I will be doing some pairing with a co-worker on Monday, and I must say that I’m really looking forward to the experience.
What Pair-Programing is Not « Blog Title // Jun 13, 2009 at 10:30 pm
[...] via What Pair-Programing is Not. [...]
“Real researchers have measured the effect of pair programming. It is as effecient as 1.25 programmers versus 2 programmers programming alone. That’s a loss of .75 programmers productivity for some quality metrics you might never be able to measure.”Which researchers? In which papers?”Maybe if bloggers bothered to google anything they wouldn’t have to rely on rhetoric, they could use evidence instead.”While I agree with the idea that anecdotes are not data, I had vague recollections that studies done on pair programming had mostly been positive. I bothered to Google. It turns out that Wikipedia has links to several studies:http://en.wikipedia.org/wiki/Pair_programmingWhich generally support the position that pair programming has a more-than-linear increase in productivity; or alternatively, that it reduces defect insertion rates.The latter is actually more important in dollar terms. It is more expensive to remove defects later than to remove them earlier. Pair programming seems to provide much of the same benefit as code inspections with less overhead.
Is there any reason you couldn’t just use a bog-ordinary comment box that doesn’t do horrible violence to my paragraphs?
@Jacques,
Plain old text box for you.
There’s a bit of a trap here in thinking that every new team member is an Arthur. Some people will get up to speed faster if you give them a quick, hands-off tour of the code base first, so that they can build a conceptual map of the code to orient themselves when they’re hands-on. So find out what kind of person you’re dealing with before setting them down at a keyboard and saying “now type this”.
I’m in the “needs a map” camp. Diving right without a map adds to my initial confusion, because of a strong need to know where I am. Building a map as I go slows me down. Give me a map up front, and the approach you’ve described works fine.
good article. I like the idea of bringing people up to speed this way. btw, third paragraph from the bottom, last sentence you have ‘paring’ not ‘pairing’, not trying to be over critical but since the web is not as static as print I think it’s good to help people correct typographical errors.
links for 2009-06-14 « 個人的な雑記 // Jun 14, 2009 at 3:12 pm
[...] What Pair-Programing is Not (tags: programming) [...]
Nice. This is the most useful description I’ve read on pair programming yet. I am so not a fan spending all day every day pairing, but this type of pairing is hugely helpful and beneficial and you’ve done a great job of capturing why.
chester, You’re reading the wikipedia results all wrong. You just paid for 2 programmers to do the job of one programmer. They are taking 60% to 100% (or more) time that the single developer is taking [Nosek]. This means that it cost you MORE in every case in just billable hours alone, (equal cost would 50% of the time) disregarding what benefits improved quality will give you. Surely with this insane loss of productivity you could’ve been more productive.
misko, the point is, it has been measured and you didn’t even bother to look, even worse you crap out anecdotal evidence and act like this is some defense.
It’s funny how people consist on pair programming being not efficient. You never ever have the situation that you have two coder with exactly the same skills! Good pairs are two people with different skills. So most of the time you improve the architecture with the driver, you get a lot better code and due to the social pressure by having sitting someone next to you, you don’t get lazy (espacially writting tests). You share knowledge of the architecture, so when one coder is ill or leaf the company the knowledge isn’t lost.
What pair-programing is not – modula // Jun 15, 2009 at 2:02 am
[...] A very enlightning article by Miško Hevery. This entry was written by Eero, posted on June 15, 2009 at 12:02, filed under Blog and tagged productivity, programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL. « When underdogs break the rules [...]
@Jonathan Hartley
You make good points about how code reviews can be inferior to pair programming, but I think a few counter-points are in order as well.
1. “Code reviews require a lengthy feedback cycle.” I agree that if it takes you 2 days to get a code review back, the developer (and t he code?) has moved on and it’s harder. But there’s no reason code reviews have to be delayed that much when everyone is in the same timezone.
At Smart Bear we do multiple code reviews per day, typically while we’re waiting for a code review of our own. Reviews rarely last as long as a day, and if it does gum up you just assign the review to someone else.
2. “Code reviews are intrinsically confrontational.” This depends on the attitude of your developers, not on the code review process.
Are you telling me that having someone whispering in my ear every time I make a mistake isn’t confrontational? Or could lead to anxiety or social problems? It could — or not — depending on the attitude of the participants.
3. & 4. “Code reviews are hard to do well and can be boring.” I think these points could equally be applied to pairs. You get tired of pointing out the nits. You get bored while someone keys in boilerplate code so you drift off or do email.
Or, during boilerplate time (or just simple code) are you wasting your time as a pair?
In summary, I don’t see how anyone can deny that in the “getting someone up to speed” category — the main subject of the blog post — pair programming is best.
But once you have programmers who know what they’re doing, perhaps code reviews take 10% of the time and, say, 50% of the effectiveness. That could be a good trade.
@Jason,
Fair points Jason, no doubt there is some value in a middle ground. I’m obviously describing what seems to work well in my experience, as are we all, I guess.
Best regards,
igorbrejc.net » Fresh Catch For June 17th // Jun 17, 2009 at 4:03 am
[...] What Pair-Programing is Not [...]
Nice post, it helped me a lot having important aspect of pair programming
@misko
Thank you for great post. I agree 100%
» What Pair-Programing is Not - Yee Torrents News 4 // Sep 29, 2009 at 2:38 am
[...] Source:What Pair-Programing is Not [...]
This is the perfect chair for pair programming:
http://www.kinnanes.com.au/bunnyheartchair.jpg
Leave a Comment