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,352

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
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,395
  • 3
  • 23
  • 41
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,103
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.

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,342
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.

Servius
  • 239