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?

ozz
  • 8,322
  • 2
  • 29
  • 62
  • I wish we used it at all. My programming team on my senior project was the only team that used it (we could use whatever methodology we wanted, as long as we had a plan) with great results. – Michael K Jan 25 '11 at 15:26
  • 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
  • 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. – Martin Wickman Jan 26 '11 at 17:51
  • @Martin Wickman: I've yet to see or hear of a situation where having two full time developers permanently pair programming is feasible. It has it's use cases, but generally they're limited. But my comment was just a comment, as I'm not really *that* experienced in such things, was only giving a gut reaction based on what I've seen, read and done. – TZHX Jan 26 '11 at 19:54
  • 1
    @TZHX: Fair enough. My experience is that pairing makes you at least as effective as two separate developers. Here is a paper on the subject: http://mitchlacey.com/docs/XR4PromiscuousPairingandBeginnersMind.pdf – Martin Wickman Jan 26 '11 at 21:25
  • @TZHX, programming is about as much to typing, as writing a book is. Programmers solve problems. Typing is merely the means of documenting a solution. And two people, working together to solve problems will almost always work faster and get more done, than two programmers working individually. – CaffGeek Mar 04 '11 at 20:51
  • @Chad - I agree on typing. I don't see how your comment is in any way a response what I've said. – TZHX Mar 05 '11 at 12:38
  • @TZHX Not to be argumentative, but extrapolating your "poor business decision" would indicate that it's a waste of money to have more than one person on a project. After all it's more than one salary for one output. – Michael K Mar 05 '11 at 20:46
  • There's a difference between utilizing paired programming development *when it makes sense*, and doing it *full time*. I really don't think doing it *full time* would be a good thing. @Michael - reductio ad absurdum isn't really a fitting way to engage in discussion in the real world. – TZHX Mar 05 '11 at 21:08
  • If you've ever had to clean-up someone else's code, you've been implementing paired-programming in the worse way and just didn't know it. – JeffO May 09 '13 at 17:47

7 Answers7

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.

DevSolo
  • 2,814
  • 20
  • 23
  • 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
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.

Pemdas
  • 5,385
  • 3
  • 21
  • 41
  • 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
  • I suppose that could happen as well, but I was thinking more along the lines of being forced to work with someone that "sucks" at what they do and has no desire or openness to being better. – Pemdas Jan 25 '11 at 16:53
  • Sounds like someone's failure to pair program because they 'suck' would provide some incentive to get rid of them. – JeffO Jan 25 '11 at 19:46
  • true story, but at big company that is harder said than done. – Pemdas Jan 25 '11 at 19:53
  • @Pemdas: So, you cannot use pair programming because team members have no motivation. Maybe the best approach would be to try finding the cause for those motivation problems and see if they can be fixed. You definitely don't need "top-notch" people for pair programming. You just need normal, motivated people. – Martin Wickman Jan 26 '11 at 15:11
  • Jeeze...I am not saying it can't be done. I am just suggesting a reason why it might not work. – Pemdas Jan 26 '11 at 15:24
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.

CaffGeek
  • 8,033
  • 5
  • 32
  • 38
  • 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 http://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
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.

Edward Strange
  • 9,172
  • 2
  • 36
  • 48
  • 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
  • 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 Jan 25 '11 at 22:51
  • @DevSolo: The way I know it, one programmer is supposed to code while the other 'reviews' the code being typed. That would be equivalent to "looking over my shoulder" for me - I, too, get uncomfortable when people watch me while I code. – pyvi Jan 26 '11 at 14:31
  • @Pyvi: "Hands on the keyboard" should be in short spam of a few minutes, especially if you also employ TDD. (I'm not advocating TDD either way.) In my experience, it's been shoulder to shoulder, passing the keyboard back and forth in a time frame we are both comfortable with. IMHO if you feel their someone "looking over shoulder", you're assuming pair is master/slave, not peer, as I've said earlier. Another way to look at is, a great way to learn something is to teach it. Pairing always 2 people to do both. – DevSolo Jan 26 '11 at 14:49
  • 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
  • @Martin, well said. – DevSolo Jan 26 '11 at 15:13
  • I agree with #1 and maybe #4, but the rest of your argument doesn't quite seem to fit with what pair programming is supposed to look like when handled correctly. It's not being corrected by someone else all the time who silently looks over your shoulder. Actually, I've read some guidelines that suggest both developers have a computer, where one codes and the other one is able to look up stuff. Even if you're the one coming up with solutions and thinking fast, you might actually be the "senior" developer in a a pair programming duo. – Anne Schuessler Jan 26 '11 at 15:40
  • 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
  • @Anne: The two computer thing is how my team in college programmed. Works great. One computer would have the code in question up, and we could both look up stuff if we needed to. Bottom line is, you need to work together. Pair programming doesn't preclude P.SE :) – Michael K Mar 04 '11 at 21:01
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?

9000
  • 24,162
  • 4
  • 51
  • 79
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.

Brian Knoblauch
  • 4,170
  • 1
  • 17
  • 20
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.

Servius
  • 239
  • 4
  • 3