8 ms·

Why Pair Programming Is Not For the Masses

93 points by fogus 17y ago

WilliamLP 17y ago
I'm completely and utterly unconvinced that two brilliant programmers can produce more than twice their usual individual output together, versus just consulting when they have an interesting question or a stumbling block. If you got Linus Torvalds and Richard Stallman sharing one computer for their working lives, would they really have produced _more_ than on two computers? I seriously, seriously, doubt it.
- duncanj 17y ago
  I don't know if LT and RMS would have gotten along in that way, but how productive over the years has each one been? If you put them on the same team and paid them well, and they had goals they shared, etc., etc., I don't find it all that unlikely.
- cracki 17y ago
  i'll bet you measure output in [LoC / hour], don't you? pairing means sharing thoughts, means thorough examination of thoughts, means validated thoughts, means code based on good reasoning.
  - WilliamLP 17y ago
    Have you got much besides straw-manning what I'm saying and proof by personal assertion?
- michaelkeenan 17y ago
  I've never tried pair programming so I don't have an opinion on it, but I do know of an interesting pair programming story about Richard Stallman. It's related by Sam Williams in chapter six of his book Free As In Freedom: Richard Stallman's Crusade For Free Software: [Guy Steele] recalls a notable episode in the late 1970s when the two programmers banded together to write the editor's "pretty print" feature. Originally conceived by Steele, pretty print was another keystroke-triggered feature that reformatted Emacs' source code so that it was both more readable and took up less space, further bolstering the program's WYSIWIG qualities. The feature was strategic enough to attract Stallman's active interest, and it wasn't long before Steele wrote that he and Stallman were planning an improved version. "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type. The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it." The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life." http://oreilly.com/openbook/freedom/ch06.html http://oreilly.com/openbook/freedom/ch06.html Of course, that doesn't say anything about what Stallman or Steele could have produced that day working separately, but it is interesting to me that Stallman pair-programmed at least sometimes.
ZeroGravitas 17y ago
Depressing but accurate reading. Even the standard "pairing sucks" advocates in the comments agree that these things are what is stopping the average IT shop from being productive and professional. And, while as I say it's depressing, it also kind of makes me feel better to know that most everybody else is in the same boat.
- ams6110 17y ago
  I think pairing sucks. Based on my personal experience with it. I'm just not cut out for it, mostly. I'm more comfortable and productive in the the "private office with a door" environment that DeMarco and Spolsky advocate. I don't dispute that pairing works for some people, in some situations. Despite the overall "we're so smart and so much better than everyone else" attitude in this piece, the still-relevant conclusion is that pairing is not easy, requires large investments in both physical assets and people who want to work that way. He even admits that once your team is larger than a dozen or so, the feasibility of pairing starts to break down because of personality conflicts.
  - ZeroGravitas 17y ago
    You've apparently been thrown off course by the love-it-or-loathe it reaction to pairing, but you're actually agreeing with the article. He's listing why it isn't feasible for most situations. (Though most people seem to interpret this as reverse psychology, though I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate). But really I could write a long (sometimes contradictory) list of things that would help people program better that would get similar levels of reaction: * use vi * use emacs * use an IDE * TDD * unit testing * any kind of testing * writing documentation * using the highest level language possible * using C++ * using anything but C++ * source control * distributed source control * avoiding gotos Judging by the slightly over-emotional responses in this thread to pairing you only need to find one good bit of software written without these tools/ideas and you can ignore them totally. Apparently, in your case, an individual not liking something, or it being hard, or requiring investment or not being suitable for all sizes of teams rules it out, which covers most of this list. I would suggest doing hard things you don't like, which require investment and need to be applied appropriately to your context is a pretty good definition of "profesionalism", something sorely lacking in most software development shops but on the other hand just because it fits that definition doesn't mean it's the right thing to do. I think that pairing, like many things in this list, can be appropriate and useful but I'm not about to burn anyone as a witch if they don't like it or practice it.
yesimahuman 17y ago
Pair programming seems like one of those necessary evils. I don't find working with a partner any fun in terms of the joy of hacking stuff out and figuring stuff out on your own, but I see the value in having multiple eyes on code, and I'm sure it could have found lots of bugs in my past.
gcv 17y ago
I had fairly bad experiences with pair programming. None of the physical reasons the author brought up applied: it was in a decent, private room, with decent hardware. The social problems did not apply: it was with cool, friendly people. It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs. One more thing. The author claims that pair programming helps avoid duct-taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"
- beza1e1 17y ago
  What kind of code was that? It sounds like churning out boilerplate stuff in flow state. The passive one should be able to join to debug failing unit tests and to listen to your thoughts.
- matstc 17y ago
  Pairing has helped me and my code a lot but as with most things there is a learning curve. Only an atrocious pair would say something like "Oh... yes, that function... I already thought of that, and here's why it can't work.". When pairing, thinking is talking. If the one not typing at the moment is allowed to get bored, then the pairing is not done correctly. Also, in my experience, two developers working as a pair will have better work ethics and discipline than any of the two taken separately. BTW, you're calling the one not typing the 'passive' one? That's the wrong attitude.
- 17y ago
acg 17y ago
Perhaps programming isn't really for the masses, many of these points just describe traits in people that cause bad software to be written period. The best teams are those who are passionate about getting software right: they'll do whatever is needed to make their software work well. Whether that is pair programming or not. Whether to pair depends on how work is organized, it really requires episodes http://c2.com/ppr/episodes.html http://c2.com/ppr/episodes.html (or usually called stories). Pairing is, for me at least, one tool in the toolbox. It is particularly good on green-field projects I've found where there are a lot of decisions to be made.
mhd 17y ago
Wow, that's one arrogant piece of writing. That still doesn't provide any good, scientific reason why pair programming is that much better -- yay for anecdotes. But I guess I'm just one of those anti-social programmers. Excuse me while I try to see which of my unwashed heavy metal shirts to wear today.
- roc 17y ago
  It sounds like you just didn't understand what he was trying to say. Maybe you failed to invest the proper amount of time in the article? Perhaps you didn't pay enough attention, because you're lazy? I suppose you might be too overworked and stressed out to get it? Could it be that you used traditional reading practices? Is your work environment not conducive to reading a top N list? It could be that your boss doesn't care about excellence, which is why he hired a twit... By chance, do you have halitosis?
  - julsonl 17y ago
    Wow, way to be hostile. These two were raising valid points in which I agree with. The article really does seem to have an attitude to it. He could have raised his point with implying almost every time that "my company is better than everybody else" kind of tone. Bear in mind that I'm not against pair programming, in fact, I want to experience that some time in my career (unless narcolepsy kicks in after being passive for so long).
    - Nwallins 17y ago
      FWIW, I believe the comment you replied to was satire.
    - santry 17y ago
      Not to speak for roc, but I believe the comment was intentionally written in the style of the original article, probably to mock it.
    - roc 17y ago
      I was lampooning the arguments of the article. I didn't think it was all that subtle, but either I was wrong or it just wasn't funny. My apologies to anyone who misinterpreted it.
myth_drannon 17y ago
"I find it best when I put a guard with a whip near each programmer. They work faster , more eager to stay long hours, produce on average x2 more lines of code. They should not forget that only 100 years ago their forefathers were working 18 hours in Manchester assembly lines factories. They should know that although it's a 21 century, the system has not changed"
garnet7 17y ago
> Hashrocket is a boutique shop, so we can be very picky about who we hire. [snip] We've hired qualified interns, but we don't hire apprentice or junior-level folks. What ever happened to hiring good people and training them?
- obie 17y ago
  It's hard to do that on a client's dime, at least for me. (I know other consultancies do it all the time and it disgusts me.)
  - boucher 17y ago
    Part of running a business is paying the associated costs. Training new employees is an expected cost of running a business, so take it out of your end. Doesn't seem like a particularly outrageous idea...
tomjen2 17y ago
Personally the idea of pair programming would suck out the joy of programming for me. I just can't stand the thought of not thinking through what I am doing and talking about it, is way slower than doing it in my head.
- beza1e1 17y ago
  I think the point is to think-and-talk instead of think-and-rewrite.
  - gdee 17y ago
    Someone who is able to think and talk at the same speed is either an impractically fast talker or an impractically slow thinker.
    - cracki 17y ago
      sacrifice "speed" for validated thought. pair programming intends to prevent rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.
      - gdee 17y ago
        Spaghetti code is not necessarily the result of fast thinking... shallow is enough... fast or slow. However, fast thinking is necessary for playing out different versions of a solution inside one's head and generally for analyzing the suitability and elegance of one. That process is fast, internal and generally not conductive of talking. Just concentration and discipline. Also, verbalizing a thinking process is always a lossy compression. At least for me. And it's not because I don't know how to express myself, although I might not be very good at that either. It's because verbalizing a thinking process always feels like serialization of an inherently parallel and real time process. The mouth is a shared resource here.
        beza1e1 17y ago
Kirby 17y ago
I, for one, get higher quality work done when I'm allowed to take breaks. This shop might be heaven for workaholics, but there's a lot of really excellent folks who just wouldn't enjoy their jobs if there was someone in the room constantly pushing them to keep working. It's great their culture works for some, but if this were the norm - I'd quit my job and go back to school in something that didn't involve computers, very quickly. Or go into management. Do they practice Pair Leadership? Didn't think so.
- cookiecaper 17y ago
  Yeah, I had this experience at my last full-time gig; our IT director and the other IT person had no concept of the importance of resting your mind in the middle of the day (along with many other important things). They would just go on for hours and hours and hours uninterrupted, doing incredibly stupid things. They even closed the blinds because they didn't want to see something outside and get distracted with it (this is how programmers wind up in their building's dungeons and basements, guys). Guy fought with me a lot because he felt that I shouldn't take breaks as such even between tasks, he said I was being paid "for my highest potential", or something like that, and that taking breaks for 15-30 minutes was unacceptable. I find this ridiculous and crazy. I also found the guy's post ridiculous and crazy. I now know I will never work for Hashrocket.
- callmeed 17y ago
  Actually, if you read the NYT article, they use a pomodoro time management technique–25 mins on, then a 5 min break. http://www.nytimes.com/2009/09/20/jobs/20pre.html http://www.nytimes.com/2009/09/20/jobs/20pre.html working hard != being over-worked ... at least that's how I understood it
  - ismarc 17y ago
    The Pomodoro technique is phenomenal. I actually end up doing ~50 and 10 rather than ~25 and 5. The trick is, when the buzzer goes off, I hit save, mash make && make test and go grab a cigarette. Chat about the weather, video games, anything really with other folks (non-smokers are encouraged to take "smoke breaks" outside, get some much needed sunlight and just relax out of the cubicles). Come back in, look at compiler output or test results and there's a list of things to start working on. If it all ran fine, continue working. Amazing how something so simple as "get up and away from your desk" does more than any "agile", "extreme" or "You're kicked from a plane, you must write a driver that interfaces the rip cord to the parachute release mechanism in order to deploy your chute" methodology.
steveklabnik 17y ago
I've only ever had exceptional experiences when pair programming. Maybe it's for reasons similar to Obie's; the people that I paired with were excellent programmers. If I tried to tell you why it was great, I'd basically be re-iterating what he said. More focus, better code, less time, less bugs, better design...
deleted 17y ago
[deleted]
hcayless 17y ago
Never really done pair programming, but I'm struck by how much it's culture-dependent, and how easily it can be undone by initial assumptions. "We'll save money on furniture." "That guy's good, but too expensive."
Flemlord 17y ago
Pair programming is an attempt to take two good programmers and turn them into one great programmer. If you hire great programmers in the first place, it is unnecessary and wasteful.
- jon_dahl 17y ago
  That depends on the difficult of what they're developing. Boilerplate code? Two great programmers are a waste. Moderate difficulty? Maybe less efficient than working separately, but they'll still work a bit faster, produce fewer defects, transfer knowledge well, etc. Really complex problem? Not a waste at all.
socratees 17y ago
> "When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice." Seems like a mindless rant to me. We can always keep modify software as we like. The same can't be said for a bridge or a human being on a operating theater. What an absurd comparison to make.
wallflower 17y ago
Pair programming works. However, I don't see the point in using it all the time - in some situations, it's only as effective as working solo. It really rocks for crisis situations (pair debugging) or new feature implementation quickly (all-night coding). Flow is a very important part of pair programming.
harold 17y ago
The rigidity of this approach surprises me. I certainly think pair programming has value. But I don't understand why this company would be so rigid in enforcing it as the only way to develop software.
- plinkplonk 17y ago
  "The rigidity of this approach surprises me" That is because you don't know Obie. HashRocket is Obie's vision about how sw dev should be done made manifest. I would go crazy working at HR, but hey the man has a right to his vision. The interesting thing is how "agilists" who pride themselves on their , err, agility are very rigid about "the right way to develop software".
- erso 17y ago
  I think you're looking at it the wrong way. Instead of people being forced to pair, they get to pair. It doesn't seem unreasonable to me that they'd hire people that want to work the way Hashrocket works.
ams6110 17y ago
Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out. Sounds like a recipe for burn-out to me. Maybe if you switch to 6 hour days, or 4 day weeks, it could be more sustainable. I did like one thing he said though, which has nothing to do with pairing... he said they require developers to purchase their own laptops. Like a mechanic or carpenter provides his own tools. That makes some sense to me. Let people chose the tools that they are most familiar with and most productive using.
- duncanj 17y ago
  I think critics tend to compare pair programming to those moments when they are most productive. One programmer in flow may be able to really crank something cool out in a day or so. He might even work 25 hours straight to do it, and really get it out there. If he spends the next week polishing, tweaking, and adding very little functionality, he doesn't include that in his comparison to pair programming. He did it in 25 hours, it took a pair of programmers three days, the pairs are slower, even though the pairs are done and have moved on to other, important stuff. Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. Plus, it's totally sustainable, and it comes with a built-in training methodology. I used to think that everyone really should start pairing. But I'm more in the camp now that people should form little organizations that pair and basically put everyone else out of business. If it's more productive, places like hashrocket are going to become the leading shops for software. Their employees are going to make twice the market rate, have social lives, good friends at work, interesting problems to work on, and relativley low stress. If it's not more productive, they'll probably eventually have trouble competing.
  - kscaldef 17y ago
    > Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. This is a non sequitur. You can work solo and still get lots done, have a social life, go out for lunch, have fun on the weekends.
Confusion 17y ago
To the average programmer, having to pair full-time means they won't get to waste time during the day on [..] Hacker News. If my employer wouldn't allow me to read HN during the day, then I'd go find another one. Constantly learning and improving myself is what keeps me going and HN helps me in that. I consider it my study time, which I otherwise don't get (one of the major disadvantages of this employer).
dagw 17y ago
In my experience pair programming works best when used on hard problems. If you're doing the sort of coding where there is no complex problem solving involved and you're basically limited by your typing speed then pair programming is probably just hindrance. However for the sort of hard complex problem that is pushing you to your limit and requires hours of thought, testing and prototyping to produce a dozen lines of production code I find it can be enormously effective if paired with the right sort of person.
kscaldef 17y ago
Let me get this straight. Did he just claim that managers need to be willing to fire someone for having bad breath? And he has the nerve to accuse others of tolerating anti-social behavior?
varjag 17y ago
Pair programming to me is a managerial gimmick to keep trench people in check, like those timesheets with specifics down to five minutes. To make them look over each others shoulder, and not surf the web. To address the near-universal management suspicion that your employees slack on the company time. (Disclaimer: yes I did read that book about the (failed) Chrysler project experience generalization to whole industry, so am familiar with the official hype part). Many people just like the way people normally work better. To do the job you assigned as you see fit, to possess quiet minutes for thinking at will, and to have full control and sole responsibility for what you do. There is time and place for interactions, that's why people have code reviews, meetings, brainstorming sessions, et cetera. If sitting on the degenerate case of meeting of two throughout all your worktime is your thing, fine, do pair programming. But as the author clearly says it is not for masses, although I beg to differ about the actual reasons.
BigZaphod 17y ago
Ugh. What a horrible article. I've done mandated pair programming in the past and I've had good and bad experiences during that time - it depends a lot on who your partner is and what the project is - there's no way it can be "the one true answer" with so many variables. My opinion is that pair programming is something that good developers do naturally when and for as long as is required. Mandating it for all development sends the signal that you think your programmers are too incompetent/stupid to trust on their own. While I'm a big believer in object oriented programming, even I can admit it isn't always a good fit for every job. Pair programming is no different. Believing otherwise is just your religion showing.
- bdmac97 17y ago
  I fail to see in that article where it advocates mandated pair programming... In fact I think it does a pretty good job of pointing out when/where pair programming does NOT work (i.e. many environments for the reasons listed). If you happen to work in an environment not conducive to pair programming and they force you to do it... well then...
cracki 17y ago
that one guy at work, he either doesn't shower often enough for his type or he never heard of deodorant. as long as the wind blows away from him (windows open), that's not a bother though. edit: i thought i should share some of my pair programming experiences and insights... one time a friend and I programmed some ATmega embedded assignment for a course. what happened was that we sat down on a couch in the library (our faculty cares!), laptops on our laps. and then the mind meld began... i mostly talked about what i was writing at the moment, what considerations i put into each call and conditional. reasoning out loud about various conditions that could or could not happen. i did that so we were on the same page and he would not hesitate to ask if anything was looking suspicious. the resulting code felt very pure, i must say. he had our plans, schematics and pinouts handy and kept track of the coding progress (this done, that left). he knew how the parts would fit together and steered the process. i should pick his brain some more on that experience sometime. the other time was at work, where a coworker got me to sit with him for my experience with the python language. he went through that rushed job of spaghetti while my eyes glazed over because i hadn't seen the code before. occasionally i pulled on this and that dangling thread to see what was attached, which gave me some insight and him some more things to fix (logic bugs mostly). that code still is buggy as hell (also because it interfaces with/works around another buggy pile of shit), which is why i asked for a real code review. code reviews are done rarely enough that i'm afraid it's gonna end without much gain.
wwkeyboard 17y ago
From a quick, unscientific survey of the discussion around pair programming it looks like most of the people who have tried pair programming like it, and most of the people who haven't think it would suck. Is anyone else noticing this pattern?
- caustic 17y ago
  The article provides 10 reasons why pair programming might not work. Moreover, it says that these reasons are very common: 10. Most software managers... 9. Most software shops... 8. Most software shops... 7. Most software shops... 6. Most software people... 5. Most software shops... 4. Most software shops... 3. Most software developers... 2. Most software developers... 1. Most software shops... Do you see the pattern: most pair programming attempts, if they happen, fail, because of "Most of the...". You write: "most of the people who have tried pair programming like it". Your conclusion is contrary to one of the the article.
run4yourlives 17y ago
Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness. You know what I think produces better measures of added happiness? Not working in a sweatshop. My major problem with pair programming is that it has the effect of treating programmers like children that need to be controlled. This is no different than the corporate drone being assigned a single task to do over and over again. It's more productive sure, but it's similarly a death march. Sorry, but people aren't cogs in a machine. They goof off, they're unmotivated, and sometimes - believe it or not - they do other things besides work. I'd much rather employ programmers in a traditional sense who are happy, goofy, disagree a lot and are somewhat productive than have a super productive team of like thinking robots, because essentially that's what you need to make pair programming work. Productivity is not the be all and end all.
scotty79 17y ago
From my experience on pair programming: - it occurs naturally if you give two programmers one computer and one problem. - one programmer becomes tactician/executor, other one becomes strategist/supervisor - tactician thinks how to make loop to iterate properly, strategists thinks why to make loop and what to do next. - it helps immensely to have someone who has different ideas than you on your side, if you are willing to submit to this ideas if you don't have other than idealistic arguments against them.
richcollins 17y ago
It seems like pair programming is quite popular with consulting companies (Hashrocket, Pivotal). You get to charge for the time of two developers instead of just one. I haven't heard of any startups that pair program. As a humorous addendum, my wife was part of a conversation where Pivotal was mentioned. She interjected, "Isn't that the company where they do couples programming?"
- caustic 17y ago
  You have spotted it. The whole Agile movement and its practices, like pair programming, are driven and promoted by consultants who make money out of it. EDIT Moreover, I am not sure whether the companies you mentioned really practice pair programming or they use it as a marketing ploy to impress they customers.
bdmac97 17y ago
I just want to point out that saying "You're doing it wrong" (as the article does) does not necessarily imply that you could be doing it right. It doesn't have to be taken as a condemnation of your skills/ability. It simply won't work in all situations and the article does a pretty good job of pointing out blockers to pairing working.
c00p3r 17y ago
Pair programing is not for everyone. Like any other method. Pair programing is for motivated, enthusiastic and even addicted people. It is a different approach to the problem, which people must have curiousness, motivation and courage to try. Try together. It cannot be forced or set up by the managers. It cannot be motivated by money. It is for passionate people, who have a desire to solve some problem or get things better together. btw, Kent Beck's "Extreme Programming Explained" stats clear that it isn't a silver bullet and it didn't work alone. Only together with testing, planing, small changes and continuous integration. It is a part of collective effort. And of course, passionate and enthusiastic people don't give a damn to things like halitosis when they're doing together that they really love to do.
evilbit 17y ago
pair programming went out of fashion for the same reason foosball tables in the office did: it was a dumb idea somebody concocted in the haze of the dotcom boom. reality eventually reasserted itself, we grew up, and learned to work like professionals. if the only way to keep your developers busy and not goofing off is to have someone looking over their shoulder, then you, my misguided friend, fail as a leader.
palehose 17y ago
Why hasn't Pair Programming extended itself beyond just programming? What about something like "Pair Accounting"? "Pair Book Writing"? I don't see anyone arguing that the cubicle office is fundamentally flawed, except for in cases where people are anti-social and don't like each other.
- vsync 17y ago
  Then you haven't been reading much. I've seen tons of objections to cubicles, some anecdotal and some based on scientific evidence such as noise levels and interruptions from people walking by and chatting disrupting flow. Even the guy that invented the cubicle hates it. His original idea was for a workstation where you could do some work standing, some sitting, use 3d space and not just 2d. I think we can all see how far from the original concept we have come. My objection to cubicles comes down to 2 things: Can't control lighting (and offices always have those wretched overhead fluorescents) and there's always that disconcerting feeling someone is standing there staring at you when you essentially have your back to the whole room.
eplanit 17y ago
Yes, arrogant and absurd. It does prove one thing (yet again). Beware of Methodology Cults. That's what Agile and 'XP' are (who'd want to name a methodology after a failed operating system, by the way). Kent Beck = Jim Jones. Beware.
obecalp 17y ago
Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them feel productive. Personally I think pair programming is overrated while code review is still underrated.
smokey_the_bear 17y ago
I've tried pair programming a few times at several companies, and while it's occasionally been great to work through a specific problem, in general I wasn't a fan, it was awkward and boring. But recently, at my startup, I've been sitting on the couch coding on the TV (because I switched over to iPhone development and the only spare mac was the TV mac mini, and it can't drive my 30 inch monitor.) Pair programming has actually been happening fluidly with this set up, and it's been great. It's comfortable to sit side by side and both have a head-on view of the large monitor.
yason 17y ago
Pair programming bad. Pair debugging good.

93 points by fogus 17y ago

I'm completely and utterly unconvinced that two brilliant programmers can produce more than twice their usual individual output together, versus just consulting when they have an interesting question or a stumbling block. If you got Linus Torvalds and Richard Stallman sharing one computer for their working lives, would they really have produced _more_ than on two computers? I seriously, seriously, doubt it.

duncanj 17y ago
I don't know if LT and RMS would have gotten along in that way, but how productive over the years has each one been? If you put them on the same team and paid them well, and they had goals they shared, etc., etc., I don't find it all that unlikely.
cracki 17y ago
i'll bet you measure output in [LoC / hour], don't you? pairing means sharing thoughts, means thorough examination of thoughts, means validated thoughts, means code based on good reasoning.
- WilliamLP 17y ago
  Have you got much besides straw-manning what I'm saying and proof by personal assertion?
michaelkeenan 17y ago
I've never tried pair programming so I don't have an opinion on it, but I do know of an interesting pair programming story about Richard Stallman. It's related by Sam Williams in chapter six of his book Free As In Freedom: Richard Stallman's Crusade For Free Software: [Guy Steele] recalls a notable episode in the late 1970s when the two programmers banded together to write the editor's "pretty print" feature. Originally conceived by Steele, pretty print was another keystroke-triggered feature that reformatted Emacs' source code so that it was both more readable and took up less space, further bolstering the program's WYSIWIG qualities. The feature was strategic enough to attract Stallman's active interest, and it wasn't long before Steele wrote that he and Stallman were planning an improved version. "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type. The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it." The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life." http://oreilly.com/openbook/freedom/ch06.html http://oreilly.com/openbook/freedom/ch06.html Of course, that doesn't say anything about what Stallman or Steele could have produced that day working separately, but it is interesting to me that Stallman pair-programmed at least sometimes.

ZeroGravitas 17y ago

Depressing but accurate reading. Even the standard "pairing sucks" advocates in the comments agree that these things are what is stopping the average IT shop from being productive and professional. And, while as I say it's depressing, it also kind of makes me feel better to know that most everybody else is in the same boat.

ams6110 17y ago
I think pairing sucks. Based on my personal experience with it. I'm just not cut out for it, mostly. I'm more comfortable and productive in the the "private office with a door" environment that DeMarco and Spolsky advocate. I don't dispute that pairing works for some people, in some situations. Despite the overall "we're so smart and so much better than everyone else" attitude in this piece, the still-relevant conclusion is that pairing is not easy, requires large investments in both physical assets and people who want to work that way. He even admits that once your team is larger than a dozen or so, the feasibility of pairing starts to break down because of personality conflicts.
- ZeroGravitas 17y ago
  You've apparently been thrown off course by the love-it-or-loathe it reaction to pairing, but you're actually agreeing with the article. He's listing why it isn't feasible for most situations. (Though most people seem to interpret this as reverse psychology, though I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate). But really I could write a long (sometimes contradictory) list of things that would help people program better that would get similar levels of reaction: * use vi * use emacs * use an IDE * TDD * unit testing * any kind of testing * writing documentation * using the highest level language possible * using C++ * using anything but C++ * source control * distributed source control * avoiding gotos Judging by the slightly over-emotional responses in this thread to pairing you only need to find one good bit of software written without these tools/ideas and you can ignore them totally. Apparently, in your case, an individual not liking something, or it being hard, or requiring investment or not being suitable for all sizes of teams rules it out, which covers most of this list. I would suggest doing hard things you don't like, which require investment and need to be applied appropriately to your context is a pretty good definition of "profesionalism", something sorely lacking in most software development shops but on the other hand just because it fits that definition doesn't mean it's the right thing to do. I think that pairing, like many things in this list, can be appropriate and useful but I'm not about to burn anyone as a witch if they don't like it or practice it.

yesimahuman 17y ago

Pair programming seems like one of those necessary evils. I don't find working with a partner any fun in terms of the joy of hacking stuff out and figuring stuff out on your own, but I see the value in having multiple eyes on code, and I'm sure it could have found lots of bugs in my past.

gcv 17y ago

I had fairly bad experiences with pair programming. None of the physical reasons the author brought up applied: it was in a decent, private room, with decent hardware. The social problems did not apply: it was with cool, friendly people. It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs. One more thing. The author claims that pair programming helps avoid duct-taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"

beza1e1 17y ago
What kind of code was that? It sounds like churning out boilerplate stuff in flow state. The passive one should be able to join to debug failing unit tests and to listen to your thoughts.
matstc 17y ago
Pairing has helped me and my code a lot but as with most things there is a learning curve. Only an atrocious pair would say something like "Oh... yes, that function... I already thought of that, and here's why it can't work.". When pairing, thinking is talking. If the one not typing at the moment is allowed to get bored, then the pairing is not done correctly. Also, in my experience, two developers working as a pair will have better work ethics and discipline than any of the two taken separately. BTW, you're calling the one not typing the 'passive' one? That's the wrong attitude.
17y ago

acg 17y ago

Perhaps programming isn't really for the masses, many of these points just describe traits in people that cause bad software to be written period. The best teams are those who are passionate about getting software right: they'll do whatever is needed to make their software work well. Whether that is pair programming or not. Whether to pair depends on how work is organized, it really requires episodes http://c2.com/ppr/episodes.html http://c2.com/ppr/episodes.html (or usually called stories). Pairing is, for me at least, one tool in the toolbox. It is particularly good on green-field projects I've found where there are a lot of decisions to be made.

mhd 17y ago

Wow, that's one arrogant piece of writing. That still doesn't provide any good, scientific reason why pair programming is that much better -- yay for anecdotes. But I guess I'm just one of those anti-social programmers. Excuse me while I try to see which of my unwashed heavy metal shirts to wear today.

roc 17y ago
It sounds like you just didn't understand what he was trying to say. Maybe you failed to invest the proper amount of time in the article? Perhaps you didn't pay enough attention, because you're lazy? I suppose you might be too overworked and stressed out to get it? Could it be that you used traditional reading practices? Is your work environment not conducive to reading a top N list? It could be that your boss doesn't care about excellence, which is why he hired a twit... By chance, do you have halitosis?
- julsonl 17y ago
  Wow, way to be hostile. These two were raising valid points in which I agree with. The article really does seem to have an attitude to it. He could have raised his point with implying almost every time that "my company is better than everybody else" kind of tone. Bear in mind that I'm not against pair programming, in fact, I want to experience that some time in my career (unless narcolepsy kicks in after being passive for so long).
  - Nwallins 17y ago
    FWIW, I believe the comment you replied to was satire.
  - santry 17y ago
    Not to speak for roc, but I believe the comment was intentionally written in the style of the original article, probably to mock it.
  - roc 17y ago
    I was lampooning the arguments of the article. I didn't think it was all that subtle, but either I was wrong or it just wasn't funny. My apologies to anyone who misinterpreted it.

myth_drannon 17y ago

"I find it best when I put a guard with a whip near each programmer. They work faster , more eager to stay long hours, produce on average x2 more lines of code. They should not forget that only 100 years ago their forefathers were working 18 hours in Manchester assembly lines factories. They should know that although it's a 21 century, the system has not changed"

garnet7 17y ago

> Hashrocket is a boutique shop, so we can be very picky about who we hire. [snip] We've hired qualified interns, but we don't hire apprentice or junior-level folks. What ever happened to hiring good people and training them?

obie 17y ago
It's hard to do that on a client's dime, at least for me. (I know other consultancies do it all the time and it disgusts me.)
- boucher 17y ago
  Part of running a business is paying the associated costs. Training new employees is an expected cost of running a business, so take it out of your end. Doesn't seem like a particularly outrageous idea...

tomjen2 17y ago

Personally the idea of pair programming would suck out the joy of programming for me. I just can't stand the thought of not thinking through what I am doing and talking about it, is way slower than doing it in my head.

beza1e1 17y ago
I think the point is to think-and-talk instead of think-and-rewrite.
- gdee 17y ago
  Someone who is able to think and talk at the same speed is either an impractically fast talker or an impractically slow thinker.
  - cracki 17y ago
    sacrifice "speed" for validated thought. pair programming intends to prevent rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.
    - gdee 17y ago
      Spaghetti code is not necessarily the result of fast thinking... shallow is enough... fast or slow. However, fast thinking is necessary for playing out different versions of a solution inside one's head and generally for analyzing the suitability and elegance of one. That process is fast, internal and generally not conductive of talking. Just concentration and discipline. Also, verbalizing a thinking process is always a lossy compression. At least for me. And it's not because I don't know how to express myself, although I might not be very good at that either. It's because verbalizing a thinking process always feels like serialization of an inherently parallel and real time process. The mouth is a shared resource here.
      - beza1e1 17y ago

Kirby 17y ago

I, for one, get higher quality work done when I'm allowed to take breaks. This shop might be heaven for workaholics, but there's a lot of really excellent folks who just wouldn't enjoy their jobs if there was someone in the room constantly pushing them to keep working. It's great their culture works for some, but if this were the norm - I'd quit my job and go back to school in something that didn't involve computers, very quickly. Or go into management. Do they practice Pair Leadership? Didn't think so.

cookiecaper 17y ago
Yeah, I had this experience at my last full-time gig; our IT director and the other IT person had no concept of the importance of resting your mind in the middle of the day (along with many other important things). They would just go on for hours and hours and hours uninterrupted, doing incredibly stupid things. They even closed the blinds because they didn't want to see something outside and get distracted with it (this is how programmers wind up in their building's dungeons and basements, guys). Guy fought with me a lot because he felt that I shouldn't take breaks as such even between tasks, he said I was being paid "for my highest potential", or something like that, and that taking breaks for 15-30 minutes was unacceptable. I find this ridiculous and crazy. I also found the guy's post ridiculous and crazy. I now know I will never work for Hashrocket.
callmeed 17y ago
Actually, if you read the NYT article, they use a pomodoro time management technique–25 mins on, then a 5 min break. http://www.nytimes.com/2009/09/20/jobs/20pre.html http://www.nytimes.com/2009/09/20/jobs/20pre.html working hard != being over-worked ... at least that's how I understood it
- ismarc 17y ago
  The Pomodoro technique is phenomenal. I actually end up doing ~50 and 10 rather than ~25 and 5. The trick is, when the buzzer goes off, I hit save, mash make && make test and go grab a cigarette. Chat about the weather, video games, anything really with other folks (non-smokers are encouraged to take "smoke breaks" outside, get some much needed sunlight and just relax out of the cubicles). Come back in, look at compiler output or test results and there's a list of things to start working on. If it all ran fine, continue working. Amazing how something so simple as "get up and away from your desk" does more than any "agile", "extreme" or "You're kicked from a plane, you must write a driver that interfaces the rip cord to the parachute release mechanism in order to deploy your chute" methodology.

steveklabnik 17y ago

I've only ever had exceptional experiences when pair programming. Maybe it's for reasons similar to Obie's; the people that I paired with were excellent programmers. If I tried to tell you why it was great, I'd basically be re-iterating what he said. More focus, better code, less time, less bugs, better design...

deleted 17y ago

[deleted]

hcayless 17y ago

Never really done pair programming, but I'm struck by how much it's culture-dependent, and how easily it can be undone by initial assumptions. "We'll save money on furniture." "That guy's good, but too expensive."

Flemlord 17y ago

Pair programming is an attempt to take two good programmers and turn them into one great programmer. If you hire great programmers in the first place, it is unnecessary and wasteful.

jon_dahl 17y ago
That depends on the difficult of what they're developing. Boilerplate code? Two great programmers are a waste. Moderate difficulty? Maybe less efficient than working separately, but they'll still work a bit faster, produce fewer defects, transfer knowledge well, etc. Really complex problem? Not a waste at all.

socratees 17y ago

> "When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice." Seems like a mindless rant to me. We can always keep modify software as we like. The same can't be said for a bridge or a human being on a operating theater. What an absurd comparison to make.

wallflower 17y ago

Pair programming works. However, I don't see the point in using it all the time - in some situations, it's only as effective as working solo. It really rocks for crisis situations (pair debugging) or new feature implementation quickly (all-night coding). Flow is a very important part of pair programming.

harold 17y ago

The rigidity of this approach surprises me. I certainly think pair programming has value. But I don't understand why this company would be so rigid in enforcing it as the only way to develop software.

plinkplonk 17y ago
"The rigidity of this approach surprises me" That is because you don't know Obie. HashRocket is Obie's vision about how sw dev should be done made manifest. I would go crazy working at HR, but hey the man has a right to his vision. The interesting thing is how "agilists" who pride themselves on their , err, agility are very rigid about "the right way to develop software".
erso 17y ago
I think you're looking at it the wrong way. Instead of people being forced to pair, they get to pair. It doesn't seem unreasonable to me that they'd hire people that want to work the way Hashrocket works.

ams6110 17y ago

Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out. Sounds like a recipe for burn-out to me. Maybe if you switch to 6 hour days, or 4 day weeks, it could be more sustainable. I did like one thing he said though, which has nothing to do with pairing... he said they require developers to purchase their own laptops. Like a mechanic or carpenter provides his own tools. That makes some sense to me. Let people chose the tools that they are most familiar with and most productive using.

duncanj 17y ago
I think critics tend to compare pair programming to those moments when they are most productive. One programmer in flow may be able to really crank something cool out in a day or so. He might even work 25 hours straight to do it, and really get it out there. If he spends the next week polishing, tweaking, and adding very little functionality, he doesn't include that in his comparison to pair programming. He did it in 25 hours, it took a pair of programmers three days, the pairs are slower, even though the pairs are done and have moved on to other, important stuff. Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. Plus, it's totally sustainable, and it comes with a built-in training methodology. I used to think that everyone really should start pairing. But I'm more in the camp now that people should form little organizations that pair and basically put everyone else out of business. If it's more productive, places like hashrocket are going to become the leading shops for software. Their employees are going to make twice the market rate, have social lives, good friends at work, interesting problems to work on, and relativley low stress. If it's not more productive, they'll probably eventually have trouble competing.
- kscaldef 17y ago
  > Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. This is a non sequitur. You can work solo and still get lots done, have a social life, go out for lunch, have fun on the weekends.

Confusion 17y ago

To the average programmer, having to pair full-time means they won't get to waste time during the day on [..] Hacker News. If my employer wouldn't allow me to read HN during the day, then I'd go find another one. Constantly learning and improving myself is what keeps me going and HN helps me in that. I consider it my study time, which I otherwise don't get (one of the major disadvantages of this employer).

dagw 17y ago

In my experience pair programming works best when used on hard problems. If you're doing the sort of coding where there is no complex problem solving involved and you're basically limited by your typing speed then pair programming is probably just hindrance. However for the sort of hard complex problem that is pushing you to your limit and requires hours of thought, testing and prototyping to produce a dozen lines of production code I find it can be enormously effective if paired with the right sort of person.

kscaldef 17y ago

Let me get this straight. Did he just claim that managers need to be willing to fire someone for having bad breath? And he has the nerve to accuse others of tolerating anti-social behavior?

varjag 17y ago

Pair programming to me is a managerial gimmick to keep trench people in check, like those timesheets with specifics down to five minutes. To make them look over each others shoulder, and not surf the web. To address the near-universal management suspicion that your employees slack on the company time. (Disclaimer: yes I did read that book about the (failed) Chrysler project experience generalization to whole industry, so am familiar with the official hype part). Many people just like the way people normally work better. To do the job you assigned as you see fit, to possess quiet minutes for thinking at will, and to have full control and sole responsibility for what you do. There is time and place for interactions, that's why people have code reviews, meetings, brainstorming sessions, et cetera. If sitting on the degenerate case of meeting of two throughout all your worktime is your thing, fine, do pair programming. But as the author clearly says it is not for masses, although I beg to differ about the actual reasons.

BigZaphod 17y ago

Ugh. What a horrible article. I've done mandated pair programming in the past and I've had good and bad experiences during that time - it depends a lot on who your partner is and what the project is - there's no way it can be "the one true answer" with so many variables. My opinion is that pair programming is something that good developers do naturally when and for as long as is required. Mandating it for all development sends the signal that you think your programmers are too incompetent/stupid to trust on their own. While I'm a big believer in object oriented programming, even I can admit it isn't always a good fit for every job. Pair programming is no different. Believing otherwise is just your religion showing.

bdmac97 17y ago
I fail to see in that article where it advocates mandated pair programming... In fact I think it does a pretty good job of pointing out when/where pair programming does NOT work (i.e. many environments for the reasons listed). If you happen to work in an environment not conducive to pair programming and they force you to do it... well then...

cracki 17y ago

that one guy at work, he either doesn't shower often enough for his type or he never heard of deodorant. as long as the wind blows away from him (windows open), that's not a bother though. edit: i thought i should share some of my pair programming experiences and insights... one time a friend and I programmed some ATmega embedded assignment for a course. what happened was that we sat down on a couch in the library (our faculty cares!), laptops on our laps. and then the mind meld began... i mostly talked about what i was writing at the moment, what considerations i put into each call and conditional. reasoning out loud about various conditions that could or could not happen. i did that so we were on the same page and he would not hesitate to ask if anything was looking suspicious. the resulting code felt very pure, i must say. he had our plans, schematics and pinouts handy and kept track of the coding progress (this done, that left). he knew how the parts would fit together and steered the process. i should pick his brain some more on that experience sometime. the other time was at work, where a coworker got me to sit with him for my experience with the python language. he went through that rushed job of spaghetti while my eyes glazed over because i hadn't seen the code before. occasionally i pulled on this and that dangling thread to see what was attached, which gave me some insight and him some more things to fix (logic bugs mostly). that code still is buggy as hell (also because it interfaces with/works around another buggy pile of shit), which is why i asked for a real code review. code reviews are done rarely enough that i'm afraid it's gonna end without much gain.

wwkeyboard 17y ago

From a quick, unscientific survey of the discussion around pair programming it looks like most of the people who have tried pair programming like it, and most of the people who haven't think it would suck. Is anyone else noticing this pattern?

caustic 17y ago
The article provides 10 reasons why pair programming might not work. Moreover, it says that these reasons are very common: 10. Most software managers... 9. Most software shops... 8. Most software shops... 7. Most software shops... 6. Most software people... 5. Most software shops... 4. Most software shops... 3. Most software developers... 2. Most software developers... 1. Most software shops... Do you see the pattern: most pair programming attempts, if they happen, fail, because of "Most of the...". You write: "most of the people who have tried pair programming like it". Your conclusion is contrary to one of the the article.

run4yourlives 17y ago

Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness. You know what I think produces better measures of added happiness? Not working in a sweatshop. My major problem with pair programming is that it has the effect of treating programmers like children that need to be controlled. This is no different than the corporate drone being assigned a single task to do over and over again. It's more productive sure, but it's similarly a death march. Sorry, but people aren't cogs in a machine. They goof off, they're unmotivated, and sometimes - believe it or not - they do other things besides work. I'd much rather employ programmers in a traditional sense who are happy, goofy, disagree a lot and are somewhat productive than have a super productive team of like thinking robots, because essentially that's what you need to make pair programming work. Productivity is not the be all and end all.

scotty79 17y ago

From my experience on pair programming: - it occurs naturally if you give two programmers one computer and one problem. - one programmer becomes tactician/executor, other one becomes strategist/supervisor - tactician thinks how to make loop to iterate properly, strategists thinks why to make loop and what to do next. - it helps immensely to have someone who has different ideas than you on your side, if you are willing to submit to this ideas if you don't have other than idealistic arguments against them.

richcollins 17y ago

It seems like pair programming is quite popular with consulting companies (Hashrocket, Pivotal). You get to charge for the time of two developers instead of just one. I haven't heard of any startups that pair program. As a humorous addendum, my wife was part of a conversation where Pivotal was mentioned. She interjected, "Isn't that the company where they do couples programming?"

caustic 17y ago
You have spotted it. The whole Agile movement and its practices, like pair programming, are driven and promoted by consultants who make money out of it. EDIT Moreover, I am not sure whether the companies you mentioned really practice pair programming or they use it as a marketing ploy to impress they customers.

bdmac97 17y ago

I just want to point out that saying "You're doing it wrong" (as the article does) does not necessarily imply that you could be doing it right. It doesn't have to be taken as a condemnation of your skills/ability. It simply won't work in all situations and the article does a pretty good job of pointing out blockers to pairing working.

c00p3r 17y ago

Pair programing is not for everyone. Like any other method. Pair programing is for motivated, enthusiastic and even addicted people. It is a different approach to the problem, which people must have curiousness, motivation and courage to try. Try together. It cannot be forced or set up by the managers. It cannot be motivated by money. It is for passionate people, who have a desire to solve some problem or get things better together. btw, Kent Beck's "Extreme Programming Explained" stats clear that it isn't a silver bullet and it didn't work alone. Only together with testing, planing, small changes and continuous integration. It is a part of collective effort. And of course, passionate and enthusiastic people don't give a damn to things like halitosis when they're doing together that they really love to do.

evilbit 17y ago

pair programming went out of fashion for the same reason foosball tables in the office did: it was a dumb idea somebody concocted in the haze of the dotcom boom. reality eventually reasserted itself, we grew up, and learned to work like professionals. if the only way to keep your developers busy and not goofing off is to have someone looking over their shoulder, then you, my misguided friend, fail as a leader.

palehose 17y ago

Why hasn't Pair Programming extended itself beyond just programming? What about something like "Pair Accounting"? "Pair Book Writing"? I don't see anyone arguing that the cubicle office is fundamentally flawed, except for in cases where people are anti-social and don't like each other.

vsync 17y ago
Then you haven't been reading much. I've seen tons of objections to cubicles, some anecdotal and some based on scientific evidence such as noise levels and interruptions from people walking by and chatting disrupting flow. Even the guy that invented the cubicle hates it. His original idea was for a workstation where you could do some work standing, some sitting, use 3d space and not just 2d. I think we can all see how far from the original concept we have come. My objection to cubicles comes down to 2 things: Can't control lighting (and offices always have those wretched overhead fluorescents) and there's always that disconcerting feeling someone is standing there staring at you when you essentially have your back to the whole room.

eplanit 17y ago

Yes, arrogant and absurd. It does prove one thing (yet again). Beware of Methodology Cults. That's what Agile and 'XP' are (who'd want to name a methodology after a failed operating system, by the way). Kent Beck = Jim Jones. Beware.

obecalp 17y ago

Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them feel productive. Personally I think pair programming is overrated while code review is still underrated.

smokey_the_bear 17y ago

I've tried pair programming a few times at several companies, and while it's occasionally been great to work through a specific problem, in general I wasn't a fan, it was awkward and boring. But recently, at my startup, I've been sitting on the couch coding on the TV (because I switched over to iPhone development and the only spare mac was the TV mac mini, and it can't drive my 30 inch monitor.) Pair programming has actually been happening fluidly with this set up, and it's been great. It's comfortable to sit side by side and both have a head-on view of the large monitor.

yason 17y ago

Pair programming bad. Pair debugging good.