Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've always been intrigued by pair programming, but in 12 years development I've never worked in a place they have employed this practice, so I have always been sceptical as to how people see it.

I wonder whether this is because of money/time (Pointy haired boss spotting two people at one computer working on the same code!!!! how dare they!) or for other reasons?

share|improve this question
8  
I think the PHB may be correct in this situation. Two people (and hence two salaries) for one output is fundamentally a poor business decision. There aren't a lot of cases where paired programming is more productive than individual, at least not "full time" - so it's just not done that much outside of mentoring new staff members or joinly working on a specific problem. –  TZHX Jan 25 '11 at 15:26
3  
Very hard to convince the pointy haired boss that this has value. –  Walter Jan 25 '11 at 15:33
3  
For new code I think pair programming has great value. The first iteration may take the same amount of time, but IME you spend much less debug time. And when two people know the same code, debugging becomes easier, because they can look independently together. "Given enough eyeballs, every bug is transparent." –  Michael K Jan 25 '11 at 15:37
1  
@Michael, not always, but sometimes I thinking pairing on legacy code can be useful. It can break down silo's and/or reduce refactoring costs. That said, I completely agree w/ you. –  DevSolo Jan 25 '11 at 15:49
4  
@TZHX: "Two people for one output is poor business". That is a seriously flawed argument and you know it (like paying programmers per line of code). Pair programming is a complex topic and should not to be dismissed so easily. –  Martin Wickman Jan 26 '11 at 17:51

7 Answers 7

up vote 19 down vote accepted

I've had the same gig for 15 years and we've recently (last 12-18 months) starting adopting Agile techniques. Where pair programming is used, the result story/feature has been implemented on time w/ less defects. I still don't think it's been employed often enough though.

Prior to our Agile adoption one other developer and I have shared the keyboard from time to time over the years infrequently (maybe once every 3-4 months). Our management team appeared reluctant but was always satisfied w/ our informal pairing as it typically accomplished a few of the following:

  • reduced silos on the team (huge win when the team is 6-8 devs)
  • produced code with less defects
  • each dev typically picked up skills from it

I would say management is reluctant but if you can take baby steps and demonstrate that the feature is better afterward (cost savings) and/or each (or one) dev picked up some skills (paying it forward), you can pick up steam if you find it a practice that suits you or your team.

share|improve this answer
    
great insight DevSolo, thanks for sharing. I'm guessing you probably have quite a stable team (low turnover of personnel?) –  Ozz Jan 25 '11 at 15:43
    
You are welcome. Our turnover has been pretty low... 4 of us have shared the same office for 15+ years though 4 relocations (across 4 buildings and 2 states)! –  DevSolo Jan 25 '11 at 15:47
    
Ironic, your alias is 'DevSolo' ;) n.b. my experiences agree with yours –  ChrisAnnODell Jan 26 '11 at 16:49

Not very common. In all the shops I've been in in the last 10+ years, I've seen it once. At the slowest and least efficient shop. It seems to create a noisy and stressful environment. One person winds up doing the driving and talking constantly preventing the other from thinking at all.

Bring the team together for code reviews whether in groups or in pairs and give developers their own space. It'll be better in the long run than chasing the latest Agile fad.

share|improve this answer

I don't care for it:

1 - I like to listen to my music while coding. Not everyone wants to hear Slayer blasting in their ears.

2 - I was brought up considering looking over peoples' shoulders very rude and get very uncomfortable when people do it.

3 - I think very fast and when I'm on a thread of solution, when I'm beginning to find an answer, getting interrupted is the very last thing I need.

4 - I can't take occasional breaks to peruse forums and newsgroups. Some might think it inappropriate anyway but I find it very important to my continued improvement. Occasionally I'll get too distracted but generally the benefit to my increased knowledge outweighs any hit to my productivity.

I suppose it might be different on other teams, but the few times when I'm actually stumped by something and NEED help I'm almost always the one who eventually comes up with the solution anyway. I am really good at what I do but I think there might be more going on...not sure, at any rate I find that I'm better off just solving the hard problems and generally better off doing it alone. Might sound arrogant, but that doesn't make it false.

I've considered that it might actually help others pick up some of my techniques but, taking #3 into account, they'd hardly be able to ask questions without breaking my train of thought anyway.

All that said, I've tried it from time to time. Sometimes it has minor benefits but I certainly can't see it as a consistent thing. The lone-wolf system works for me and it seems to work for the team.

share|improve this answer
    
Thanks Noah, great persepctive!! –  Ozz Jan 25 '11 at 19:52
2  
@Noah, based solely on #2, I'm not sure if you grasp the concept of pair-programming. The idea isn't to look over a shoulder. The idea, as I've practiced it, is to share the PC to work in tandem. It's not master/slave programming, it's peer programming. Perhaps the later is a better term for it... –  DevSolo Jan 25 '11 at 21:07
    
This is perfectly valid. Some people just want to be left alone to figure it out on their own. –  MattC Jan 25 '11 at 22:50
2  
@Noah: Reading your list, it seems you are missing the finer points of pair programming. I'm not saying it's for everyone, and it certainly takes time and effort switching from cowboy mode to sharing mode. Just as it takes time learning how to do TDD properly (or any other agile practice for that matter). –  Martin Wickman Jan 26 '11 at 15:00
1  
continued...: With "senior" meaning that you might not actually be the one doing the code, but helping a more junior developer come up with a suggestion. I'm also not the biggest fan of the idea of pair programming, but I see that it's probably mostly being out of my comfort zone. A lot of developers like to work on their station alone, but I must admit that I would probably learn more and find better solutions of I was working together with another developer. So it's really a question of personal comfort vs. working more effectively. –  Anne Schuessler Jan 26 '11 at 15:41

Haven't done it officially, but whenever I'm stuck, I'll call a dev over and we'll both work on a solution together. It's a great way to bounce ideas, let one person think while the other implements, so you don't lose your train of thought because you are typing it out.

Wish it was done more.

share|improve this answer
4  
Another tool to use, if you're not familiar, is called "Rubber Ducking". Basically, put an object on your desk like a rubber duck (yours truly uses a toy Yoda) and explain the problem to it. see c2.com/cgi/wiki?RubberDucking –  DevSolo Jan 25 '11 at 16:46
    
I use the person sitting next to me instead...we can't put stuff on our desks. –  CaffGeek Jan 25 '11 at 17:00
    
Seriously? –  Michael K Jan 25 '11 at 17:32
    
@Michael... you have no idea the rules we have here. And yet, the few good things outweigh all the bad... barely. –  CaffGeek Jan 25 '11 at 17:39
    
It's sad to hear those unreasonable rules management applies to the programmers (That's pretty dumb, don't you think? They have to put extra effort to keep us happy to balance that) –  Zekta Chan Jan 26 '11 at 14:41

We never called it that, but back in the day, that's how we always attacked new problems. We'd pair up to get started on a solution, but then usually break out to individually finish/clean up the details. Not so much anymore. Seems to becoming rarer and rarer.

share|improve this answer

My guess is that there would probably be a lot of resistances from the developers. Do you remember being forced to work with people that were perhaps not the most motivated individuals in the world during college or even high school? Those people still exist. Unless, you have a team composed of all "top-notch" people, this type of setup will cause some animosity in the group.

share|improve this answer
    
Very true Pemdas! –  Ozz Jan 25 '11 at 15:37
2  
+1, unfortunately. Teamwork is a skill that you have to develop, and if you don't want to, you can't. Maybe that's what programmer's managers should do - find the team structure that promotes the most productivity with the people they have. –  Michael K Jan 25 '11 at 15:40
4  
This profession requires keeping ego's in check. It's not always easy, but the rewards will be extremely beneficial. –  DevSolo Jan 25 '11 at 15:41
    
@DevSole...what does that have to do with my answer exactly? –  Pemdas Jan 25 '11 at 15:42
    
@Perndas, I was assuming, perhaps incorrectly, that the resistance would be due to egos. At least when I've seen it, that appears to be the reason. I've only seen 2 (that I recall) devs actually resist this. One's ego couldn't fit in the room, the other had issues w/ confidence. –  DevSolo Jan 25 '11 at 16:38

Pair programming is a great way to start or to do something non-trivial and difficult. More routine and simple tasks are better done alone.

I participated in a number of sessions of pair programming, both in startup / garage companies and big corporations. It invariably happened only when something new and difficult was being incepted, that is, twice a year at best, for a few weeks. How often does this happen at your company?

share|improve this answer
    
less often than I'd like that's for sure. –  Ozz Jan 25 '11 at 15:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.