IT Employment

Is 'pair programming' in your future?

Some claim that sharing a desk and one computer with another programmer is the most efficient way to code.

I'm not a programmer so I cannot speak for those who code for a living, but here's a concept that could take some getting used to: pair programming. This is where two people share one desk and one computer, with one person being the "driver," controlling the keyboard and typing in code, and the other being the "navigator," monitoring design and scanning for bugs.

It all started with a book: "Extreme Programming Explained," written by Kent Beck, creator of the Extreme Programming and Test Driven Development software development methodologies. According to the book, software should be released quickly and improved along the way. This is best done more quickly, according to Beck, by double-teaming projects.

Beck practiced pair programming at a software company in the ‘80s with Ward Cunningham, the developer of the first wiki. Cunningham asked Beck to check for bugs in a software application he was working on. As time went on, the two would pair up to knock out assignments so they could move on to their own pet projects.

The practice is spreading. Pivotal Labs, a software-development shop that was bought by EMC Corp. in March, has its 175 engineers pair all day, every day. Facebook has begun using the practice, as has the San Francisco-based company Square, which says about 15 percent of its engineers pair full-time.

And there are different versions of paired partnering as well: Playing the field, or changing partners daily, is called "promiscuous pairing." Hopping back and forth between partners is called ping-pong pairing. Even those who work remotely can take part: Remote pairing lets programmers share the same screen via the Internet.

Not everyone is onboard with the concept. Australia-based software company Atlassian created a mock instructional video called "Spooning" that hilariously mocks the practice.

So what do you developers say? Is this something you would be comfortable with?

About

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

42 comments
Tumbleweed_Biff
Tumbleweed_Biff

I have been involved with paired programming in the past and I love it. Obviously as noted by Charles Bundy, it does depend upon who your partner is. However, the code produced is far cleaner and more efficient than that produced by most single efforts. There were significantly fewer defects in the code submitted for QA, shortening the QA feedback loop dramatically. Overall, production code was released much faster with fewer defects than with single developer code and the process cost less than single developer coding. It looks more expensive up front, but the overall cost is much cheaper. Having two pairs of eyes with different perspectives on things results in conversations about why do things one way rather than another, there is an instant logic check and many logic errors are discovered immediately rather than being run through QA or (heaven forbid) being released to production. Remember the cost progression for coding errors: found in development cost X to fix. Caught in QA costs 10x to fix, etc. How often have you as a developer spent hours and hours on one approach only to have to give up and go another way? Having someone else present frequently catches such errors much earlier saving countless hours. It works and is quite effective.

RMSx32767
RMSx32767

40 programmers needing only 20 desks and computers means less money spent on resources (human or otherwise) = more money in the pockets of the managers and executives ! Like any other method(ology) the success or failure depends on who is involved, have they "bought in" and "climbed on board", do they understand the method, with whom will they be paired? I've worked with some whom I could have indeed worked VERY closely; had I been forced to work with others, someone would have to die.

phil.beach
phil.beach

Who you are partnered with can be a real impact to someones productivity. Besides the different thought process, and programming styles to get in the way... this would be a nightmare for someone that's very proficient at developing software. My fingers are moving before I can even verbalize my thought process, so how would a partner keep up? On the upside, early in my career I was fortunate enough to work closely as a pair with a very talented developer. I thought I was good until working with this individual and I learned more in that short period than I had in previous years coding. But I have to believe I was a drag on this guy too -- His career choice wasn't to be a trainer. With 30+ years as a developer / project leader, I would hate to be paired. From the manager side on my brain, if one or the other got sick or injured (heaven forbid), then the organization would be in a much better position to stay on course. Still I got divorced for a reason -- I don't need to be second guessed and bitched at regularly :)

Mick_S
Mick_S

Seriously, I don't see how I could manage that. I work on three projects simultaneously. I will work on one piece of code, start it through its testing process, then go work on another piece of code for a separate project while the first one is testing. I am able to pump out more work than most of my colleagues, but my scattershot work process would probably drive someone else crazy if they tried to look over my shoulder. I work at the office and at home. Most importantly, as mentioned above, we don't have enough developers to do all the work we need to do in the first place, so I don't see how this could ever work at my office.

jonathan_alvarez
jonathan_alvarez

It is hard to drive a car with 2 pilots, the one with the wheels on the hand normally get upset (ask your wife ;) ) , but it is not impossible, just need a lot of communication, suggestion deals, time and money money. With some time one will become the driver and the other the navigator. But I don't want to be the navigator either :P

bratwizard
bratwizard

I have long said that there seems to be three main types of programmers, (1) the "Lone Wolf" type, who works well by him or herself and doesn't need or want help. (2) the "Pair programmer" (or "Duo", as I've always called them) who work well with each other. In a good duo, they complement each other's strengths and weaknesses, help add energy and keep enthusiasm levels up, and often accomplish a surprising amount. And (3) the "Team programmer" who works well in a full team environment, tasked by the team (or team lead / manager) and working on smaller portions of the project and collectively arriving at the goal. I don't think any one "type" is especially "better" (or worse) than any other type, but its important to realize what type someone is and enable them accordingly. So you don't toss a "lone wolf" into a duo or a team, etc., and expect peak performance. I think its probably mostly about personalities, but possibly also about individual backgrounds and skill sets.

sealbee
sealbee

My co-worker and I were not told to do this but this is just how it worked out sometimes. It seemed to work really well because issues could be fixed before the first test of the new code.. as sections of code were added. We kept each other from taking shortcuts. The observer could bring up special case scenarios while the typer was working through creating or patching together the current condition. Then the structure of the various routines could be modified before they were ever finished. This is also good because you learn each other's ways and increase your tool-kit. So yes, I think this is a good idea although I wouldn't want to be forced to work this way for very long with the wrong people. If you believe that two brains are better than one then this will work. People are saying there isn't enough people to do this but how long does it take to put out code that doesn't work only to correct it later when possibly with another person reviewing it real time so to speak, the issue could have been avoided in the first place. Basically the 'other' person has to be actively engaged and driving the development as much as the person typing.

joelleitner
joelleitner

With the right coding partner this can be the best thing ever for productivity (I've had a couple of such partners). With the wrong partner, it is a disaster (I had one of those, too). Lots of little things, from programming/testing style to quirky personal habits can make or break the arrangement. So it should *never* be forced on programmers, but should definitely be encouraged when it occurs organically. As the previous commenter noted, it's actually a lot like a marriage (or dating)...

richard233
richard233

I've had trouble working in the same office with some people, let alone have someone looking over my shoulder, and I'm not saying its all their fault. I "do" work with management with the interface design. They state changes and I make them. These are usually cosmetic in nature and fairly easy to implement. When it comes to true coding, I tend to work in bursts. At times I may seem to be doing little, at others I'm generating at a frenzied pace. Peer review of code changes can be useful. Having someone available to help you troubleshoot some code even more so. Having someone there waiting on you to produce or you waiting on them .... not so much.

TheLip95032
TheLip95032

Extreme programming and the rest of the"new" approaches to "manufacturing" software are good for selling books or someone's PhD thesis but in the real world no one gets that much time or has those resources available to them. In most places you would be lucky if you could get enough work space to put your coffe cup down.

GSG
GSG

I'm not exactly a programmer, but I do create interfaces between medical systems. As I build my interface, I create the interface in sections, each section being devoted to a different task, then I use my stored data to test that section. When that's done, I move on, and test the next section. When all sections are tested, then I test the translation as whole. If I get the result I expect, then I release it for validation testing. Using this method, I can whip out a fairly complex translation in a couple of hours, and the validation process takes less time. If I have to create my translation, then move from my keyboard for someone else to test, that will slow things down. I won't have a clear understanding of what went wrong with the test. Maybe I didn't compile, or I had a variable mis-identified, or something else that's easy. It seems that it would defeat the purpose to have someone else see the error and then try to tell me what the error was so I could try to figure out how to fix it. I'm all for collaboration as we've solved some pretty big problems, but it seems to me the share desk and computer is a waste of resources. Am I going to just sit there and pick my nose, or take a nap while the other person is testing?

jolisadillard
jolisadillard

1) Skill set of the person you pair with? 2) Will the partner have the project completion in mind or will that partner be there to try to shine above their partner? 3) Compatability of the 2 people-Have you had to work with someone you do not like? 4) The work ethics comparable to complete the project in a speedy and efficient manner? 5) As previously mentioned the programming styles are they compatible.

sysop-dr
sysop-dr

I have used this a few times. Most times this is done with another programmer but in a few cases where the user champion is really interested with how the process works and knows what they want you can do this with a non-programmer and they can work with you just as well as another programmer can. What you end up with then has a lot more buy-in from the user champion and the users. I have done this with a medium level manager once as well. He wanted to see what I do and I wanted him to have some sweat equity in the product. He had some good ideas (and a few bad ones) and we were able to implement them quickly or show why we shouldn't implement them. He then was a lot more supportive of the product which then got me more finding and testers. (I can usually get the programmers I need but getting funding for testers is not always easy. For software that has an impact on safety testers should outnumber the programmers.)

mwclarke1
mwclarke1

Sharing all office furniture, only one desk chair and someone has to sit in the others lap Seriously though, just an attempt by businesses to try and save the extra dime by cutting computer assets in half When such draconian practices all proven to be major non productive ideas. Anytime I meet strong resistance to work in an appropriate environment, I move to another job quickly, I do not like to change, but when forced I have an overload of continuous job offers even in this economy, I do not have to work for evil people

lharbour
lharbour

For the design and planning phase, the more eyes to search for flaws and suggest ideas the better. When it comes to actually writing code...well, to put it nicely, most developers tend to be rather "confident" in our ability and who among us doesn't believe in our heart of hearts that our approach is best? While the knowledge sharing inherent in paired programming is positive, in practice, it's difficult to imagine a bigger barrier to progress than two developers sitting at a monitor and haggling endlessly over some trivial aspect of code. More importantly, pair programming should never be substituted for a good peer review and testing policy which I suspect it sometimes might be.

andrew232006
andrew232006

I'd find it very difficult to work with someone constantly looking over my shoulder.

sybaseguru
sybaseguru

Had pairs working together in late 80's doing agile programming - they reviewed each others code so they could discuss differences in coding style and content and ensure compatibility. I found a lot of bugs were avoided as differences in interpretation were clarified. It also led to high productivity due to competition between the programmers to produce high quality code quickly - neither wanted to be picked up for buggy code.

jdudeck
jdudeck

Any expectations of a company that all their programmers should work in pairs does not take into account differences in temperament and personality type. A person who is an introvert, such as I am, would never be able to work that closely with another programmer. It is a certain recipe for stress disorders, and would put somebody in the hospital within weeks. (I once had a supervisor who caused me so much stress I ended up in the hospital. And I am a very easy-going guy). On the other hand I could see it working for programmers who are gregarious, and who need discipline to focus on their work. But I don't understand why these people would ever become programmers in the first place...

ondcross
ondcross

Yes, And then there is the college effect where the group doormat does the work while the other sits on the duff doing nothing except potentially taking credit. I've worked at places where not only is the programming half staffed, but half of the half is either doing nothing or 'management'. What ever happened to having a good work ethic and actually rewarding people? Oh yeah. EoE and other maxims like this that are worthless because the idea is mentioned and someone blindly goes with it.

tooblessedtofail
tooblessedtofail

I think pairing is a good practice especially promiscuous pairing where you pair with totally different people. You learn more that way or contribute more. The issue I have with it is that sometimes I just want to have my space to myself- you know. So I am in favour of it but NOT all the time like full time. Remote pairing is good too. I have practised it. Flawed Internet access is probably the only inhibiting factor in this case.

Jeff_D_Programmer
Jeff_D_Programmer

The situation I've found that seems to work best is to pair 1 sr. developer as a navigator to (no more than) 3 jr "drivers". The drivers get experience and training, and the navigator checks for bugs, conventions, and goldbergs. High productivity, low error rate, happy developers, and upper management feels comfortable.

mdv3441
mdv3441

Being a contractor, I have been paired with a contractor from another firm. I spent more time training than writing code, then basically put my foot down. I believe in cross training when a full time employee, or training a member of the company I am working for. As a contractor, I believe that's why I was brought in on a project for my knowledge and more than a bit against training another agencies developer.

shadowgreg
shadowgreg

It has been a bit over six years since I began developing software and web applications for a living rather than a hobby, and since I graduated from university. The only experience I have had with this has come within the past 12 months out of that entire time, and have noticed that it can become a debate of various issues such as best practices. The main benefit I have noticed from it so far is the ability to learn from each other when using this sort of technique, such as when a developer is being cross skilled in a new language. It can also be generally great at breaking through mental barriers when I am, or my peers are stuck trying to solve a problem as the process of describing the problem can even allow you to figure out the solution yourself. My preferred method is to independently work on code and peer review the changes each of us have committed when merging into the chosen repository, and use this technique only when trying to increase the general knowledge of the team as a whole, pushing through any barriers and reducing any points of failure which may exist (when only one person knows how to look after or do something).

tango_chuck
tango_chuck

We use the same driver, navigator or "right seat ride" concept during training or to resolve issues and troubleshooting. As with most of the comments I see here. Most IT groups are not really designed for this mentality. It is let's get as much productivity out of each individual as we can and therefore the the whole team by default. I have observed that the pairing technique does work marvelously when in a training environment or case by case basis for support issues. I wouldn't mind seeing a study to verify if the pairing technique makes a productivity impact. After all two sets of eyes are better than one. Pairing does bring up unique issues of the usual problems that companies deal with: work schedules, personaity conflicts, skill sets, work area footprints, equal opportunity, gender preferences etc etc etc.....

Tony Hopkinson
Tony Hopkinson

To get the most out of it you need to pick the right project, basic enhancement stuff for instance, it's a waste of a programmer and a half. You also need to work on your pairings. We all have our own ways of thinking about a problem, I've seen two people arrive at the same solution with radically different approaches, and two people achieve equally acceptable but different solutions. As Slayer says though, the time and motion, bean counter types have a real problem with this concept. Get gung ho with it, and all they see is chance to cut staff in half, and we all know that as well. We do tech because we like it, not becasue we are too stoopid to figure out standard corporate SOP. Choose your targets wisely. It needs to be a reasonable block of work, either adding a new feature in one place, or enabling a new one across the piece. There needs to be several potential solutions or none. If there's "only one way" to do it no point in having two people doing it. The pairs need to see the value of it, bouncing ideas off each other spotting holes, disseminating domain or technical knowledge. Other options are available, group design, peer review, hot housing. They are all tools in the box, use the right one at the right time. Anyone who sells any of them as a silver bullet, has simply got bored with offloading bridges to greedy idiots.

Charles Bundy
Charles Bundy

Pair programming depends largely on who you get as a partner. ;)

janakee
janakee

In 1975 I completed a 4 month full time structured COBOL program course. Peter Gambel and myself were picked up by the BTR computer department. As they were 1 desk short in the developers section we both ended up sitting at one desk. We work on 3 projects together. Coding sheets and punch cards in those days. As we had come off the same training course we thought identically in terms of naming conventions, top-down programming design, sub-routine coding, line numbering, etc. The great experience still remains with me. Debugging sure was a breeze when we checked out each others work. Get it a try it might just surprise you Donavan McDonough

Slayer_
Slayer_

What dev department is staffed well enough to do this, I want to join them. So far every dev job I have had, has had only half the people they need and refuse to hire more.

Tony Hopkinson
Tony Hopkinson

that you weren't viewed as a drag. In fact I'd say that you needed to get a bit more out of it and take as much enjoyment out of bringing on the young and capable as he did. If he had felt as you do, he would have been as effective at it as you would seem to be. To be effective at training you have to want to do it. Sitting by Nellie is not pair programming, if you aren't both contributing and making use of each other's ideas and approaches, it's not a pair.

Tony Hopkinson
Tony Hopkinson

As one knows how to driver better in the conditions, and the other knows the best route to where they want to go. If they aren't swapping they are not realising the development benefits of pair programming. They are hopefully gaining the training benefits though, so they should get back up to speed as pair shortly.

Tony Hopkinson
Tony Hopkinson

Attempts to substitite peer review for testing, many times. While potential or actual bugs of whatever type might be found in a pair or by a peer, neither are testing.

Tony Hopkinson
Tony Hopkinson

While there are and should be training aspects around pair programing, it should not feel like you are being criticised, if it does you are paired up with the wrong person.

Tony Hopkinson
Tony Hopkinson

but the whole point of effective pair programming is two can do the task nearly as fast as one, with the bonus of two people comprehending the code, and just as important how it ended up like that. Working with another programmer, is not working for a supervisor, even or perhaps especially, ones who at least believe they can program. Your last paragraph is simply insulting, introverted != competent.

Tony Hopkinson
Tony Hopkinson

The sort of numbers that would satisfy the time and motion boys are the same ones they use in the equation 1 man for two weeks = 2 men for one week, which as we all know is complete drivel even discounting the knowledge and skill levels of the developers. Now if you looked at the numbers around the lifetime of a piece of software, including training, coping with staff rollover, key person dependencies etc, I'm morally certain pairs is a good move. Can't prove it, though and it doesn't matter anyway, because the time and motion boys don't look past the this deadline.

mckinnej
mckinnej

One of Murphy's many laws is that putting 2 people together in an office gives you a 90% chance of a personality conflict. (I think it jumps to >99% when we're talking about the same cube.) That's just how it is. It can take months, maybe years to put together a cohesive pair that doesn't want to kill each other. About the time you find that perfect match, one of them gets a job offer and all your effort is shot. It's one of those things that is great when all the stars align and the universe is in harmony. Unfortunately it doesn't happen very often and trying to force it doesn't really work out all that well. From another perspective, our positions are individually scrutinized and negotiated with the customer. Might as well ask for the moon as ask for 2 people to do what they perceive as one job.

Tony Hopkinson
Tony Hopkinson

Some programmers I've worked with have drove me mental with their approach. Nothing wrong with either of us, just think very differently. At best leaves one or the other nodding, and making the tea.

Tony Hopkinson
Tony Hopkinson

were they? Don't try and take the credit, pair programming is new, it says so on the label. :D

aroc
aroc

from what I have seen. But, no, I do not think that is an absolute qualification - just a tendency that goes with the degree of mental focus and concentration often needed (at least with my style of programming back when I did that more exclusively). I have just seen a reference in another discussion to a study of what accounts for good vs poor programming results, and a hugely predictive factor was the degree to which programmers were NOT forced into "social" working situations, but could have their own space - pay and experience mattered far less. Someone where I work brought this up in reference to our workplace's growing use of open workspaces - pick your chair and work table spot for the day, and plug your headset into the IP phone, and set up your notebook and keyboard/mouse from your overnight equipment locker. This is beyond pairing - more like "herding" (cats no less). Many of us in IT are cringing at the prospect, and desperately trying to qualify for the exemptions (or looking for other jobs). I am working mostly from home, and it is not fully set up at our worksite yet, but "The Doom" is approaching ;-). I had the experience of working with a colleague in one of those settings at another site, and it was terrible ... for me. She was a very soft-spoken Indian, and her table-mates of the day often drowned her out when we were trying to collaborate via phone. It seems some work situations/modes/personalities simply will not fit this model. YMMV

aroc
aroc

That's around the time I started programming (yep, COBOL, and "stuctured" when that was the hot tech), and with moving between desk and card punch machine and dropping off the decks to be read into the computer, and waiting for the printouts - yeah, it could have worked ... then. Nowadays, although I am more of a web admin than a programmer, I usually have a dozen windows or more on 2 monitors going, and when I am not checking on processes, debugging crashes, fine-tuning monitoring tools settings, installing updates, starting/stopping services, and even dabbling in my "hobby" of writing ksh utilities to help with the foregoing, then I use the "spare" time (yeah, right) to catch up on emails, respond to chats, and catch up with endless online learning - share what, exactly? Also, I see the hard-core programming types in other cubes at times, and they seem to keep multiple monitors, and even PC's, going just by themselves, so I have trouble visualizing them sharing their hardware. However, online collaborative work modes with screen sharing, code check-out/check-in, and other such techniques make more sense as a 'virtual' method of doing something similar. Something weird about this notion...

Tony Hopkinson
Tony Hopkinson

Which sad little man marked this down. Pathetic.

aroc
aroc

Right - collaborating does take that discussion, although it can be via IM chats for physically separated folks (more accurate sometimes, if not screen-sharing), but I was referring more to my employer's cat-herding plan ("cat houses"? ;-} ), with lots of people in close proximity.

Tony Hopkinson
Tony Hopkinson

Throwing random individuals together to make a pair is going to even less successful than trying to build real teams that way. An ineffective pair is going to be less productive than one individual never mind two. Programmers tend to be introverted on average, say compared to sales types, but in most cases they don't have a problem discussing programming with anyone. If fact trying to shup them up about it, is a bigger issue. :D

Editor's Picks