Forgot your password?
typodupeerror
Programming

The Programmers Go Coding Two-by-Two — Hurrah? 318

Posted by timothy
from the simple-chronic-pairitosis dept.
theodp writes "The Wall Street Journal reports that pair programming is all the rage at tech darlings Facebook and Square. Its advocates speak in glowing terms of the power of pair programming, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web. 'The communication becomes so deep that you don't even use words anymore,' says Facebook programmer Kent Beck. 'You just grunt and point.' Such reverent tones prompted Atlassian to poke a little fun at the practice with Spooning, an instructional video in which a burly engineer sits on a colleague's lap, wraps his arms around his partner's waist and types along with him hand over hand."
This discussion has been archived. No new comments can be posted.

The Programmers Go Coding Two-by-Two — Hurrah?

Comments Filter:
  • by Peter Cooper (660482) on Tuesday August 28, 2012 @11:33AM (#41149723) Homepage Journal

    Like many workplace practices, it's something worth trying, but not something to be trumpeted as "the way" to do things. Some people get on with pairing, some don't. And it's OK either way. Likewise, there are writers who work in pairs, but many who do great work alone. There are architects who work in groups and alone. So it goes for software developers.

    Where it goes sour, however, is when people who find pair programming valuable start tarring anyone who doesn't do it as being error-prone slackers.

    • by O('_')O_Bush (1162487) on Tuesday August 28, 2012 @11:42AM (#41149873)
      It also works better for inexperienced programmers than it does for seasoned vets. Partly because of egos, partly because problems don't end up being as difficult to solve.

      Also, there is the problem of getting tired, where programming ends up being handed off between partners while the other partner zones out, and at each handoff, one has to come back up to speed. Surfing the web is bad for some, but for many programmers it is an opportunity for one to collect and organize their thoughts, and attack problems from new angles.

      I've heard pair programming increases productivity by 150% over a single programmer, but two programmers independent are still more efficient than a pair. I believe this to be accurate, after a few months experience.
      • by mooingyak (720677) on Tuesday August 28, 2012 @11:47AM (#41149951)

        It also works better for inexperienced programmers than it does for seasoned vets.

        My understanding of the process is that it's ideally a pair with one seasoned vet who is supposed to have the large view and one junior programmer who is supposed to be handling the details while learning from the seasoned vet.

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          Yeah, if you want the seasoned vet to commit seppuku...

          • Yeah, if you want the seasoned vet to commit seppuku...

            Nonsense. One of the tasks implicit for any seasoned vet (especially one that is vested as a senior or principal) is to guide juniors or new members of the team up to speed. Obviously, you don't want your vets to be paired with juniors all the time, as this is not economical (and at some point the junior needs to hit the ground running by himself/herself).

            However, in any company (and for any job for that matter) it is a person's task to help others come up to speed if that person has the necessary know-h

        • by AwesomeMcgee (2437070) on Tuesday August 28, 2012 @01:30PM (#41151875)
          No, this is a magnificent technique for mentoring, but this is *not* pair programming. I can't stress how great it is for mentoring though. Turn a Junior into a mid-level engineer real fast.
          • by SomePgmr (2021234) on Tuesday August 28, 2012 @04:01PM (#41155265) Homepage

            You used the word, "mentoring". It occurs to me that people have been doing this in virtually every trade for centuries in more traditional apprenticeships.

            I was in a situation similar to this as a programmer. Nobody had planned for us to work in pairs, it just worked out that way. The bit in the summary about the two of you learning to basically read each others' minds is pretty accurate.

            One guy tends to introduce the more creative, interesting ideas, while the other (probably more experienced guy) sees when you're missing the forest for the trees. The end result is, hopefully, more impressive work that's not so impressive that it fails at basic functionality.

            It worked out really well for us. Of course, YMMV.

        • i find co-ed naked pair programming to be the most productive; especially when looking to start a new branch.

        • Re: (Score:3, Interesting)

          by xtracto (837672)

          I have seen a problem in that in the time I have done pair programming.

          When I am the 'seasoned vet' I get quickly frustrated by the slowness of the person who is writing. On the other hand, when the writer is more senior than I am, oftentimes I just cannot follow what he is doing, if he goes too fast (like when doing Vi-editing).

          This maybe except with one particular very good senior who was saying out loud what he was doing *as* he was doing it.

          • by Jane_Dozey (759010) on Tuesday August 28, 2012 @03:35PM (#41154691)

            Yes, I've worked with people who are great at pair programming and those who are not so good. I find that when working with someone who really gets PP you end up with two programmers (or more!) working together, both of them on the same page, catching mistakes and improving how the code is written.
            When working with someone who just starts coding and expects their partner to magically understand what they've decided to do then it can be impossible to keep up or figure out what on earth they're doing. At that point you have a programmer programming and another programmer wasting their time scratching their head.

            PP works wonderfully when you pair people up correctly and train everyone involved how to effectively work like that, but if you don't then you waste resources and frustrate your coders.

        • by gutnor (872759) on Tuesday August 28, 2012 @03:33PM (#41154657)

          That is the most difficult pairing you can make unfortunately. Either you put the vet as the driver and the junior will simply not follow or get bored. Or you let the junior drive and then it becomes a dictation. In both case, the junior brain shut down and it relies on what's written/dictated and stop thinking for himself.

          You want junior dev to struggle a bit on their own so they have the opportunity to evaluate various options. That process is enhanced in pair with another junior developer. Immediate feedback from a more senior dev is in my experience slowing the learning process and killing the creativity of the junior.

        • I currently work like this, being less experienced programmer. You know what, it was much better when I worked in pair with same level programmer. When both programmers are equally experienced (or inexperienced), the relationship is very friendly and motivating, as both persons are learning and helping each other.

          When one of them is more experienced than the other, it immediatly turns into boss-subordinate relationship, which is not good. It turns out that not only you are at disadvantage and supposed to ca

      • by jellomizer (103300) on Tuesday August 28, 2012 @12:00PM (#41150203)

        I found paring inexperienced with experienced developers actually work a lot better.

        1. Ego - Developers need to keep their ego's aside. There Egos is what keeps them doing the wrong thing over and over again. A fresh young mind to challenge his decision really helps him rethink what he is doing.

        2. Experience - The new guy doesn't have experience, experience isn't how fast you code, but to know what gatcha will get you, unless you account for them early. New developers tend to code themselves in a box. More experienced developers keep a hook open to add changes in particular areas where they know there will be a change (even though non of the specs say it will change), Experience workers can teach them why they break the rules when they do.

        3. Trading Skills - Having one code owner is dangerous, having a few developers knowing what is going on is very handy. The idea of coding yourself a job, is often short sited because you have coded yourself in a position where you cannot advanced. Plus giving young developers skills to work and advance in the project is a good thing too.

        4. It restricts getting tired - Coders will pass off the boring stuff back and forth so when you are at the 80% complete mark, you have energy to fill in the 20%
         

        • by slim (1652) <john.hartnup@net> on Tuesday August 28, 2012 @12:31PM (#41150665) Homepage

          Great points all. I'll add:

          5. It keeps you honest. Coding is full of temptations to cut corners. But you're less likely to cut that corner if someone else is watching -- and you won't let a colleague do the kind of lazy things you'd do yourself.

      • by Surt (22457)

        I'd be very curious to know how you're measuring productivity. Our experience has been that pairing results in more than 200% productivity.

        (For our definition of productivity, which includes the long-term maintenance effort on the resulting code).

        • Re: (Score:3, Informative)

          by Gr8Apes (679165)

          Mine's been pretty much consistently <50% productivity for the pair.

          Why, you ask? Because 2 senior people working on web services can knock out 2 web services in 'x' timeframe, or 1 when paired, in 'x' + 'y' timeframe, where 'y' is a number equal to or greater than 0. The same goes for any other component functions.

    • by man_of_mr_e (217855) on Tuesday August 28, 2012 @11:45AM (#41149915)

      I agree. Not everyone can work in pairs. And certainly there are many people who cannot work in pairs with certain other people. It really requires a good friendship to make it work.

      I actually stumbled across this myself in 1994 when I was forced due to time constraints to work with another programmer to finish a project... we sort of accidentally did pair programming and it was very effective.

      But i'm not sure I could recreate that kind of synergy again.. I've tried and it didn't work.

      • by jythie (914043) on Tuesday August 28, 2012 @12:03PM (#41150253)
        Sadly there seems to often be an attitude of 'I selected programmers who are ideal for X, X worked, therefor X is the way to program!'... which if you follow the mantra too closely can really limit your pool of talent since not only do you have to find someone who is good at the job, but someone who enjoys working in that very specific environment..... it decreases workplace flexibility.

        Then again, with the rise of brogammer culture, I gather a lot of place are not concerned with flexibility or diversity in the first place and actively encourage mono-cultures. And of course it is another way to push out all those pesky introverts who keep thinking they are people.....
    • Re: (Score:3, Insightful)

      "Some people get on with pairing, some don't."

      And if they're just getting into it now, they're only about 6 years behind the curve.

      But why should I be surprised? Considering that Facebook was based on PHP?

    • by fermion (181285)
      15 years ago I knew a few senior programmers that did this. Like the current case it was internal software that would never be distributed to external customers. It all ran in house, was updated frequently, so overall quality was not as important as rapid development. Serious bugs could be recalled instantly, less serious could be rolled out in day or two. Which is to say I think pair programming, if that is what the kids are calling it now, might be very workable for certain people and certain situatio
    • by ifrag (984323)
      I've found it to be valuable for short time periods working through either specific integration tasks or refining certain code that multiple people have had input on. Or sometimes just as a sort of natural thing where I'd bring up an issue with someone and we'd work through it right then. I'd probably go crazy and find another job if I had to pair program all the time.
      • by Fallingcow (213461) on Tuesday August 28, 2012 @01:14PM (#41151469) Homepage

        Shit, I spend more time reading docs, googling, staring in to space thinking about problems, and doodling ideas and flows on paper than I do actually coding. I'd think it would be hard for two programers' true coding time to line up well enough for pair programming to work, and you'd have to allow time for them to share any breakthroughs they'd had between sessions, unless you tried to pair-think too, which sounds annoying at best. Bouncing ideas off co-workers as necessary is one thing, but beyond that it seems counterproductive.

        Maybe this works if you have a very top-down structure with an engineer/analyst up the chain handing you every single thing you need and defining in extremely precise terms how everything last detail should be implemented so there's nothing left to do but type, and maybe decide which kind of loop to use or whether to use switch/case versus if/else or whatever.

  • by sticks_us (150624) on Tuesday August 28, 2012 @11:33AM (#41149725) Homepage

    But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much.

    I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I started doing this about 15 years ago in college. I was working on a project with a partner, but we only had one computer between the two of us. He did most of the typing, while I discussed design with him, helped debug, and pointed out typos. It's like an instant code review.

      Of course we didn't call it "pair programming" at the time. But I've done it at every opportunity since.

      dom

    • by O('_')O_Bush (1162487) on Tuesday August 28, 2012 @11:45AM (#41149913)
      That is because new programmers don't have experience solving problems, and end up getting stuck spinning their wheels. For them, programming is the challenge. For more experienced people, the programming is trivial, it is the design that is a challenge.
    • by macbeth66 (204889)

      Interesting. In my office, it seems the the opposite is true. I thought it was because the younger ones had the attention span of gerbils on speed.

      Just don't pair me with a girl.

    • by perpenso (1613749) on Tuesday August 28, 2012 @11:48AM (#41149983)

      But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much. I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?

      Or it has something to do with experience. The elder programmers have seen many programming fads come and go, many claims for the "one true way" to greater efficiency and reducing bugs. Like most fad/pop things, pair programming probably worked in a specific environment, with specific people doing a specific type of task ... but is probably not a universal solution. It is merely hyped as such by the "training" industry, book sellers, etc.

      Elders may realize when working in pairs will help and when it will not. I've seen plenty of instances when elders call in a peer for an hour or two for a particular bit of code and then part when returning to the more mundane parts of the code. Or ask a peer to review a bit of code they just wrote.

      • by pclminion (145572) on Tuesday August 28, 2012 @12:11PM (#41150349)

        The elder programmers have seen many programming fads come and go, many claims for the "one true way" to greater efficiency and reducing bugs. Like most fad/pop things, pair programming probably worked in a specific environment, with specific people doing a specific type of task ... but is probably not a universal solution.

        I have to disagree. At its most basic, pair programming is simply having somebody directly help you to accomplish a task, and also, observe your actions as you make them. The concept of using a helper is not a fad, trend, or technique. A better term for it would be "no brainer." The reason it sometimes fails is because of the personalities involved, and it's the same reason certain people can't work together doing ANYTHING (for instance, repairing a car).

        It's true that programming often requirements moments or even extended periods of intense, solitary concentration. Your partner just has to know when to shut up. Even with compatible personalities it still takes practice.

        But really, it's just two humans working together on something, which is not a "fad."

    • by vlm (69642) on Tuesday August 28, 2012 @11:50AM (#41150011)

      I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?

      After you live and work through 10 or so silver bullet fads you'll get a bit jaded at "oh god not yet another silver bullet that'll magically fix everything if we just change everything and hire some expensive consultants".

      http://en.wikipedia.org/wiki/No_Silver_Bullet [wikipedia.org]

      My main whine about pair programming is its a bastardization of ye olde master/apprentice. Oh so close to being correct, yet still miss the target. That's worked in about a zillion other fields for only about a zillion centuries. I learned a lot as an apprentice from some good masters and taught a few apprentices as a master, hopefully well. Pair programming claims master/apprentice inevitably leads to "watch the master" where the apprentice sits around and learns nothing. That's wrong; its not an inherent effect of master/apprentice, it's an inherent effect of shittymaster/apprentice. It does correctly show that having a con man or moron as master doesn't work, or maybe the older the programmer is the more important it is that he not be an idiot. Also its the apprentice's job not to be passive... ask why, ask how it works, ask what other options exist, etc.

      I suppose you can't charge $xxx/hr as a consultant or book author merely by telling the boss to set up something like a medieval blacksmithing guild, gotta come up with some new twist on the old story.

      • by iluvcapra (782887)

        Pair programming claims master/apprentice inevitably leads to "watch the master" where the apprentice sits around and learns nothing.

        Sounds like the master in that case is just saying "move over kid, let me do it" all the time. Naturally software development is an attractive field for control freaks -- people who came to computers specifically because computers follow precise instructions, need to be taught nothing, and require no patience or emotional consideration. Many other crafts require intensive te

    • by jythie (914043)
      I have gathered that today's culture is slowly trying to push out the personality types that were common 20 years ago. Programming used to be a highly stigmatized 'nerd' domain filled with introverts... today there is a lot more cash and social acceptance behind it, so the field is getting filled with people who are far more sociable and extroverted. It has also been pushing out women.. CS is one of the few STEM areas that has actually gotten worse when it comes to gender ratio over the last 30 years, wit
      • "I have gathered that today's culture is slowly trying to push out the personality types that were common 20 years ago."

        I didn't realize "competent" was a personality type but sure, makes sense.
    • When they started to code depends a lot...
      Past-1985: (Computers were considered magical thinking machines) If you could make a computer work you were a God, if you are still working you have invited a good portion of our infrastructure. You were the Egg Heads who made the organization improve by a large percentage. Having those new kids who doesn't even know what a floppy disk is, seems insulting to you.

      1985-1995: (Computers were considered closer to a Bulldozer, big bulky does the job) Chances are you we

  • by Kadagan AU (638260) <[kadagan] [at] [gmail.com]> on Tuesday August 28, 2012 @11:34AM (#41149745) Journal
    If the Facebook team is using pair programming for their mobile apps (on all platforms!), maybe they should try something more traditional because it's not working! They have so many bugs and glitches in the IOS, Android (tablet), and Blackberry apps that they definitely need to try a new approach! Maybe if they TESTED them before releasing, they'd have better results?
    • by alphax45 (675119)
      RIM makes the BlackBerry app; not Facebook. Same as Twitter. Might change with BB10 but right now Facebook and Twitter don't see value in making apps for Blackberry, so RIM does it themselves.
    • Their Graph API seems alright.
    • Maybe they should get Microsoft to write them the mobile Apps. I haven't had any major problems with the WP7 Facebook App.
  • Pair or 1 + 0.3? (Score:2, Informative)

    by Anonymous Coward

    All the time i did pair programming it was me doing all the work and the other guy just pointing silly stuff like "missing ;"

  • by macbeth66 (204889) on Tuesday August 28, 2012 @11:36AM (#41149779)

    I can't think of ANY one that I want to spend that much time around.

    My wife can't code, but I would not want to spend that much time with her either.

    Now, maybe my girlfriend. But I don't htink we would get much coding done. Besides, she can't code and I don't care.

    • by slim (1652)

      Well, that's fine and all; you're a Myers-Briggs type "I" for "introvert". But other people are type "E" for "Extrovert", and are at their best when collaborating face-to-face with someone else.

      Perhaps traditionally the "I"s were just absent from programming. But increasingly the profession is attracting people who thrive on teamwork, and *like* interacting with people.

      In any case, we're not talking about solid 12 hour hackathons as pairs. We're talking, say, 4 hours out of a day, with breaks. And ideally y

      • by dkleinsc (563838)

        Well, that's fine and all; you're a Myers-Briggs type "I" for "introvert".

        He can't be *that* introverted, if he's having to decide between his wife and his girlfriend.

      • by clintp (5169)

        Perhaps traditionally the "I"s were just absent from programming.

        I can't cite anything (other than 30 years of programming) but I believe this to be wrong. My elders in this field were all introverts.

        In any case, we're not talking about solid 12 hour hackathons as pairs. We're talking, say, 4 hours out of a day, with breaks. And ideally you'd be rotating pair partners regularly.

        I'm an introvert. This isn't a disease, something to be cured, medicated, or dealt with. It's the way I am. Even for "4 hours o

  • >and are less likely to waste time surfing the Web

    You obviously haven't heard of the phenomenon of "pair surfing".

    • by cellocgw (617879)

      You obviously haven't heard of the phenomenon of "pair surfing".
      No, but I'm rather familiar with the term "pair production" (hint: quantum mechanics).

  • Two-by-two is four, duh.
  • by Barandis (2717353) on Tuesday August 28, 2012 @11:41AM (#41149849)
    I know it's just a summary and all, but it makes me feel vaguely sad that out of all of the things you can say about him, Kent Beck is tagged as a "Facebook programmer."
  • XP again (Score:3, Interesting)

    by gl4ss (559668) on Tuesday August 28, 2012 @11:42AM (#41149859) Homepage Journal

    so it's eXXXXXTreeme programming again?
    couldn't they at least fucking re-use the term.

    oh and it's not so bad for some small crunch period.. but for longer periods it really shits on my slashdot browsing habit.

    am I now officially old? since they tried selling us this XP shit back before I dropped out of uni.

    • Pair programming is a subset of extreme programming. Extreme programming deservedly fell out of favor at the end of the 1990's.

      • by geekoid (135745)

        And that's a shame, because it worked extremely well. I was on a team the produced a lot of code, and when delivered, there was 1(one) bug reported. 450,000 lines of code, one bug.

        It's down side is it take management buy in on the customer side.

    • Re: (Score:2, Troll)

      by squiggleslash (241428) *

      Reposted from years ago, my experience of Exxxxxxxxxxxxxxtreme programming! [slashdot.org]

      The team was divided into pairs. One programmer programmed. The other's job was to look for mistakes, and then yell at the first for making the error. If the error was severe enough, he would announce it on the loudspeaker. What constituted an error was never clearly defined. Sometimes it was a logic error, or a typo, but other times it was allowing code to be too flexible and too open for future expansion, even when that was the be

  • by Anonymous Coward on Tuesday August 28, 2012 @11:42AM (#41149863)

    More Programming, Motherfucker. [programmin...fucker.com]

  • Can we attribute the less then stellar applications coming from these two firms to the pair programming paradigm?

    I'm sure there are better examples to use besides these two.

  • by YrWrstNtmr (564987) on Tuesday August 28, 2012 @11:47AM (#41149969)
    If my boss sees this, and pairs me up with L.....before day one is out there will be two fewer programmers. One dead, and me in jail.
  • by YodaSensei (1486541) on Tuesday August 28, 2012 @11:48AM (#41149975)

    We used to call that eXtreme Programming: that was the rage a while ago, then went out of fashion in favour of other agile development methods. But that happened a lifetime ago (the early 2000s :p ), and computer fashion have changed more times than I can really keep track.

    I guess that the people who were actually programming 10 years ago are now managers, gurus or architects and want to bring back their happy childhood memories (id est, programming with their buddy) back to reality, imposing it on the newer generations.

  • Worth trying (Score:5, Interesting)

    by Divide By Zero (70303) on Tuesday August 28, 2012 @11:48AM (#41149977)
    Everybody poo-poos it, I'm a better coder on my own, the other guy's wasting time, etc. But I tried it and I was never a better coder than when I was working in a pair. You'd get all the "missing semicolon" stuff that everybody talks about, which isn't exactly a waste, but you also have two brains deeply enmeshed in the code and data structures, so you can blend the best of two styles of programming. Sometimes I'd write a braindead construct and the other guy would simplify it, and sometimes he'd create this god-awful structure and I'd clean it up. But you can bounce ideas off another programmer without having to explain the function, show him the code, let him get his head wrapped around it, all that. It's not all grunting and pointing, sometimes it's, "Dude, use a switch/case" or "Just use the library function."

    It's not for everybody - nothing is - but it's definitely worth trying with an honest effort.

  • I love the idea of less web surfing. I have observed that paired programming is great for weak programmers. The sort who can sort of program but aren't really that good. Two of them together usually add up to one good programmer. Two good programmers often add up to a great programmer, but the great programmers often move quickly enough that there is little or no benefit to their pairing. Just sit them really near each other.

    Basically it seems that paired programming eliminates weaknesses rather than emph
    • by gstoddart (321705)

      The sort who can sort of program but aren't really that good. Two of them together usually add up to one good programmer. Two good programmers often add up to a great programmer, but the great programmers often move quickly enough that there is little or no benefit to their pairing. Just sit them really near each other.

      You have to work at it (and that implies being willing to), and I would agree that for every single task it might be a bit much.

      But, many years ago I worked with a team of other coders, and w

  • by ddd0004 (1984672) on Tuesday August 28, 2012 @11:53AM (#41150075)

    We have one big cube with one computer and we put all of the programmers in there. We call it the stable and the programmers are now just referred to as the herd.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      We have one big cube with one computer and we put all of the programmers in there. We call it the stable and the programmers are now just referred to as the herd.

      I guess that is about as close to stable Hurd will ever be.

  • by i_ate_god (899684) on Tuesday August 28, 2012 @11:53AM (#41150083) Homepage

    Just be disciplined with design and code reviews and be done with it.

    This doesn't sound like a plan to improve performance, it sounds like a plan to cut costs on hardware, now you can have one computer for every two devs.

    • by tgd (2822)

      Just be disciplined with design and code reviews and be done with it.

      This doesn't sound like a plan to improve performance, it sounds like a plan to cut costs on hardware, now you can have one computer for every two devs.

      I think its a technique favored by "programmers" who are averse to the process involved in "engineering". From that standpoint, its probably good. If you're not going to define requirements, properly document and review what needs to be written, and have a process in place to validate quality (in which code reviews is just one part), then putting two engineers in front of the screen helps.

      I think its a false economy, though -- you're paying 2 salaries for some fraction of 2x the output of a single programme

  • Yep (Score:5, Funny)

    by Quiet_Desperation (858215) on Tuesday August 28, 2012 @12:07PM (#41150299)

    I think we can all see where this is going.

    Programmer centipede.

    You know I'm right.

    • Instead of the evil doctor, it will be a manager hovering over the programmer centipede screaming "Feed her! Feeeeed her!". Garbage in, garbage out I guess.
  • Ok in small doses (Score:5, Insightful)

    by composer777 (175489) * on Tuesday August 28, 2012 @12:13PM (#41150367)

    I've had experience with pair programming. In my mind here are the pro's:
    1. It keeps you engaged and prevents your mind from wandering.
    2. It is a great way to teach junior level programmers, many of whom suffer from a lack of training and are thrown to the wolves in the beginning of their careers. I would have LOVED pair programming (in small doses) when I was starting out. It's a great way to learn things about a complex system that are not obvious.
    3. Different people tend to approach problems differently, and this difference in perspective can make it easier to catch bugs that are not obvious to a single programmer.

    The Cons:
    1. When abused, it can reduce productivity by distracting coders and not allowing them the space they need to think.
    2. It can create a hostile environment where the employee feels that they have no privacy, room to think, and where they are constantly being watched. This is part of why I think management loves it so much, they are outsourcing micro-management to their underlings.
    3. It can reduce motivation of individual developers since the buck no longer stops with them, but instead is the group's (or pair's) responsibility. While diffusing some responsibility across the team is not a horrible idea, people tend not to be as motivated. I observed motivation take a big nose dive when the shop moved to XP, since people were no longer as accountable for finishing anything, they just had to come up with a BS explanation for what they did the past day during the scrum, and really, it's a lot easier to BS one day at a time than it is to explain just what the hell you've been doing the past two months.
    4. Many poorly designed XP programming environments are inherently disrespectful, and are merely an attempt to turn a programming shop into a factory floor with no privacy. As a skilled programmer, I won't go along with this, and I actually refused to move into this kind of space at my last job, and instead left, along with the majority of seasoned developers.

    Overall, I can get some of the benefits of pair programming by walking down the hall, grabbing another team member and saying, "Hey, could you take a look at this?", when I'm having trouble finding a bug. It shouldn't require them to sit there all day.

  • HERE WE GO AGAIN here we go again ...

    anything that is supposed to be The One True Way rapidly finds out how wide the "edge cases" are.

    In pair programming this is found in trying to put Orange/Green Irish programmers in a "pair" (or Jew/Muslim) and also is BAD for programmers that are best setup in a "den" and then have Food/Drink shoved into a slot in the door.

  • by Shoten (260439) on Tuesday August 28, 2012 @12:16PM (#41150407)

    Let's face it...this is yet another iteration of the dance we've seen before. Extreme Programming, Agile Programming, and so on. Companies keep hoping that there's a methodology that can be applied to the process of coding and development that will homogenize their workforce, allowing them to look at coders more like cookie-cutter individuals. There are multiple drivers behind this: the difficulty of assessing a programmer's talent during the recruiting process, the desire to use cheaper resources, especially in outsourced business models, and the challenges that result from coders who turn out not to be a good fit with their role. But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.

    • by Shagg (99693)

      But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.

      What some want is for it to be more like "paint by numbers". Sometimes it's OK, but as you say, most of the time it's a poor fit.

  • 'The communication becomes so deep that you don't even use words anymore,' says Facebook programmer , cosignatory to the Agile Manifesto, and inventor of Extreme Programming Kent Beck.

    Fixed that for you

  • 1999 (Score:5, Insightful)

    by nitehawk214 (222219) on Tuesday August 28, 2012 @12:20PM (#41150479)

    1999 called, they want their useless waste of resources techniques back. Nice try Kent trying to jam Extreme Programming on us again.

  • by Dunbal (464142) *
    Facebook is known for its flawless code.
  • Pair programming to me is just a bunch of snake oil. I've tried it a few times, once voluntarily and the rest of the time under pressure. Why it doesn't work for me is probably a highly subjective thing, but here goes...

    1) Switching "driver's seat" requires that you keep getting back into that state of mind that gets things done; highly inefficient and annoying.

    2) If you're paired with an inexperienced developer, you spend most of the time hand-holding; correcting a missing ; is one thing, having to explain

  • The best organizations use a blend of methods; they don't fall into the trap of forcing everyone to work the exact same way at all times.
  • by Bob9113 (14996) on Tuesday August 28, 2012 @01:35PM (#41152003) Homepage

    Facebook programmer Kent Beck.

    That seems a little like saying, "Google employee Vint Cerf."

    And, as an aside: Damn, Kent. Facebook? I thought you were cool.

You can do more with a kind word and a gun than with just a kind word. - Al Capone

Working...