16

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?

13
  • 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
    Commented Jan 25, 2011 at 15:26
  • 3
    Very hard to convince the pointy haired boss that this has value.
    – Walter
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 at 15:49
  • 5
    @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. Commented Jan 26, 2011 at 17:51

7 Answers 7

20

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.

3
  • great insight DevSolo, thanks for sharing. I'm guessing you probably have quite a stable team (low turnover of personnel?)
    – ozz
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 at 15:47
  • Ironic, your alias is 'DevSolo' ;) n.b. my experiences agree with yours
    – ChrisAnnODell
    Commented Jan 26, 2011 at 16:49
11

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.

10
  • Very true Pemdas!
    – ozz
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 at 15:41
  • @DevSole...what does that have to do with my answer exactly?
    – Pemdas
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 at 16:38
9

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.

5
  • 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
    Commented Jan 25, 2011 at 16:46
  • I use the person sitting next to me instead...we can't put stuff on our desks.
    – CaffGeek
    Commented Jan 25, 2011 at 17:00
  • Seriously?
    – Michael K
    Commented Jan 25, 2011 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
    Commented Jan 25, 2011 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
    Commented Jan 26, 2011 at 14:41
9

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.

10
  • 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
    Commented Jan 25, 2011 at 21:07
  • This is perfectly valid. Some people just want to be left alone to figure it out on their own.
    – MattC
    Commented Jan 25, 2011 at 22:50
  • And also, +1 for the headphones thing. I blast metal and/or trance all day long and get pretty annoyed when people talk to me about stuff. Can't they wait until my favorite song is over? :D
    – MattC
    Commented Jan 25, 2011 at 22:51
  • 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). Commented Jan 26, 2011 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. Commented Jan 26, 2011 at 15:41
5

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?

1
  • less often than I'd like that's for sure.
    – ozz
    Commented Jan 25, 2011 at 15:35
5

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.

3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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