8 ms·

Pair Programming Considered Harmful?

46 points by Qwl 15y ago

pmjordan 15y ago
The headline doesn't really reflect the article, though after all its waffling before getting to the point I don't think any of its conclusions are all that revolutionary. It comes down to this: when developing software in a team[1], you have conflicting requirements. Your programmers/designers need to communicate effectively enough with each other[2] to keep them pulling in the same direction, but you want to optimise individual productivity. The optimal balance will depend on the project, team size and of course the individuals involved. It will even fluctuate wildly throughout the project. So really, the best thing you can aim for is to create an environment that's flexible enough to adjust to a balance that is close enough to the optimum of the day. I'm disappointed anyone still believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. There is no substitute for common sense. Still, I was pleasantly surprised after my considerable initial trepidation about reading a programming article on TechCrunch. [1] or probably doing anything else creative, but I can't speak from experience [2] and, let's not forget, communicate with the actual users of the software
jackfoxy 15y ago
two coders at one keyboard... Pair programming without dual keyboards and mice deserves castigation.
- derekp7 15y ago
  Is there any good way to have two keyboards, two mice, both act semi independently? That is, I want two mouse pointers, and if mouse A clicks on a window, I want keyboard A bound to that same window; same with mouse B and keyboard B (and of course they can also each click on and be bound to the same window as needed). Preferably a Linux solution, but something on Windows would be OK also. What often happens, is someone would ask me to help them look at something, but they are multitasking multiple problems. Initially I can take over their keyboard & screen, but before long another call comes up and I have to transfer the problem / environment back to my desk, and get back to them (or end up owning the problem completely). I think having the keyboard & pointer independence combined with an editor that lets you have multiple windows attached to the same edit buffer (like Emacs) would be wonderful.
  - dustineichler 15y ago
    You could try mirroring monitors.
    - derekp7 15y ago
      But in that case, both monitors are still tied to the same workspace, and only one window can be active at a time. I'm looking for a way to have two active windows, each with its own keyboard attached.
      - dustineichler 15y ago
        This might be worth a read. Tom Dale wrote about his setup. There's a reference to how Pivotal Labs is setup too. I prefer the later if you can afford it. http://tomdale.net/2012/01/tildes-pairing-setup/ http://tomdale.net/2012/01/tildes-pairing-setup/
suresk 15y ago
I really dislike paired programming, and if I ever end up in another situation where all or most of the day is spent sharing the keyboard with another developer, I think I'd go insane. My first experience with it [1] was pretty bad from both a happiness and productivity perspective. I've always thought that for the purpose of improving code quality and transferring knowledge, a formal code review process is much, much better. Indeed, I've always wished more development shops would utilize a code review process of some sort. 1. http://www.spenceruresk.com/2009/03/impaired-programming-how-neither-of-us-is-as-dumb-as-both-of-us/ http://www.spenceruresk.com/2009/03/impaired-programming-how...
- pmjordan 15y ago
  I find pair programming is useful for overcoming a specific problem, after which you have to disband and each go off on your own. Examples: - The problem can be that programmer A is stuck on a piece of code or debugging: this is usually part of a bigger task which A has as the top thing in their mind, but for some reason can't make progress. Programmer B brings a fresh pair of eyes to the table, but looking at it alone makes no sense, because their mental model will be up and running much faster with A's help. - Onboarding. Programmer B is new to the project and programmer A gives an increasingly hands-on crash course of the project workflow and B's first task. - The high-level parts of major refactorings. Neither A nor B will have the whole existing structure of the code completely in their heads, but between them they have a more complete picture and stand a much better chance of not messing it up. None of these should take more than a few hours, or maybe a day max, or you probably will go insane, yes. It probably also depends on personality, but you should hopefully not have any homicidal tendencies after just a few hours.
  - suresk 15y ago
    Sorry, I should have worded that a little more carefully. Yes, I agree there are situations where a limited-duration pairing is useful and even ideal. It is only when pairing consumes most of your day for days or weeks on end that it gets really tiring and counter-productive.
    - 15y ago
MatthewPhillips 15y ago
Looking at a specific problem for a short period of time (10 minutes) with another competent programmer is one thing. But trying to concentrate with another person looking over your shoulder is aggravating. My experience is that you are more likely to take shortcuts to get the task over with. You don't want to do anything that is going to take real concentration because concentration is impossible when another person is likely to interrupt your thinking to converse. That is by far the worst part of pair programming. Knowing that your mind is free to explore a problem to whatever depth is necessary is absolutely critical to solving something non-trivial. I find it really hard to explain the damage of interruption to non-programmers. Whether it is a girlfriend or a client that likes to talk while you're fixing their bugs. I don't think it is necessarily unique to our profession, but it is certainly rare enough that most people seem not to get it.
dustineichler 15y ago
This [redacted] pisses me off, I'm sorry. Jon writes well, but I read the New Yorker article on "Group Think" which he references... in TechCrunch. I'm as shocked as you are. It's speaks well of individual creative process and how brainstorming and really other processes are bull crap. Technically speaking. If you think back, before Agile and other methodologies came along, developers were doing more with less than I'd consider any of us are doing now. For the most part. Pairing works, no doubt but I _hate_ how institutionalized it's become. I'd work at Pivotal if I could, but they pair 100% of the time. I consider myself an introvert, for the most part too. Pairing is painful if it's not organic. The article is inconsiderate article because it's speaks nothing to the fact that our profession was built on the backs of people who are socially awkward and enjoy privacy if not a certain level of autonomy.
jonstjohn 15y ago
The company that I currently work at uses pair programming extensively - not 100% but strives for 3 hours per day. Although I understand its value, actually doing pair programming can be exhausting and tedious. I've also found myself working twice as hard/fast during non-pairing hours b/c I knew that pairing would sometimes be painfully slow. Lately, I've tried to work productively with my pairing partner in tandem, rather than sitting in front of a monitor together 3 hours a day. I love the company that I work at, so I'm not likely to let pair programming dissuade me from staying there, but when if and when I do look for a new job (or start my own company), I would be very wary of a shop that uses pair programming extensively. I really love working in a team and directly with others on projects, but pair programming can be very tedious, particularly if there is a big gap in experience between the two people in the pair. We also use code reviews for all code that goes to production. I find this to be extremely valuable. For more complex pieces of code, we do 'design proposals' that are circulated within our small team (4 developers) to get feedback and improve the design of our code.
- osivertsson 15y ago
  Yes, it is my experience too that pair programming works best when you both are at roughly equal levels of experience and both really want to succeed with the task at hand. Code reviews in groups often work really good despite different levels of experience though. It is exhausting to do pair programming, but when it really does work the feeling of progress and mutual knowledge sharing is awesome. In these optimal cases me and my coworkers have worked in pairs for 5-6 hours per day. Pushing on for longer would not have gained anything, rather the opposite.
  - AlisdairO 15y ago
    In support of pair programming with a knowledge disparity, I have to say I've found it a fantastic way of bringing new team members up to speed. Yes, it's a bit of a pain in that it can bring productivity down for a while, but I really feel that it has long-term benefits.
  - mtts 15y ago
    I work with a lot of interns these days, doing what's essentially pair programming with them and I don't feel their lack of expertise brings me down at all. Instead, I find having to explain everything I do to them brings a clarity to my own mind that is difficult to obtain otherwise. Of course it does help that when my explanations truly fail, I still have the nuclear option (Hey, they pay me to teach you this stuff, so just believe me) available, but (I'd like to think) I only rarely use it.
lukev 15y ago
Off topic, but the "considered harmful" titling meme annoys me. Dijkstra gets a pass, but it's now become a passive, cliched, content-free, overused way to say you disagree with something.
- tikhonj 15y ago
  My first reaction upon reading the title was thinking of the essay "Considered Harmful” Essays Considered Harmful[1]. [1]: http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html And the quality of this article just proves the point, I think.
- zeeed 15y ago
  logging in to upvote parent. to me, tc has lost its journalistic credibility a while ago.
  - tincholio 15y ago
    >tc has lost its journalistic credibility a while ago. Around the time it was founded, I'd say
mattiask 15y ago
I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increase general quality risk being offset by decreased productivity of the top performers. If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best. This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly. The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer. It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right. If you can manage it, hire really good developers and get out of their way.
- skrebbel 15y ago
  your entire point is based on that 10x productivity rule. it keeps popping up. Is it just someone's gut feeling turned into an urban myth or have real studies been done?
  - 15y ago
pairing 15y ago
I pair 100 percent of the day so 8 hours a day for the last year. It has been a very rewarding process. As a natural introvert pairing has made me a much more communicative person and my programming ability has significantly leveled up as well. We pair with 2 monitors, 2 keyboards, and 2 mice facing each other with our own desks which I feel gives each person in the pair enough privacy and space to make us both very comfortable. Is pairing intense? Yep. Is it worth it? Absolutely in my mind. The high quality of the code and the productivity is well worth it.
- dustineichler 15y ago
  I'm glad you said that, but setups like yours are the exception not the rule. Last I was there, PL has the same. I'd mostly agree too it's a rewarding experience, but it needs to do done right. If you half ass the setup, it gets frustrating quickly.
  - pairing 15y ago
    Agreed. We started the project at Pivotal so that is where we got the setup, and I agree that it makes a huge difference. It's a shame more companies don't implement pairing correctly. The extra grand (less if you don't go with an apple display) for the monitor is a small price for the results you get.
    - dustineichler 15y ago
      They're known for distilling culture and values on clients. It's apart of their high value-added proposition i think. e.g. - best practices.
- pmjordan 15y ago
  Do the screens display the same content, and do the input devices control the same cursor? I find this 2-desk pair programming a curious arrangement.
  - pairing 15y ago
dinkumthinkum 15y ago
This is definitely YMMV territory. On the whole, I think a formal pair programming process is probably a bad idea. I wouldn't want to work somewhere where I had to play that game. Perhaps, that just means I would be a poor choice for such a company. :) However, I wonder how many of the "great" who's-who of programmers would have actually liked such a process; sure, you can find some examples, probably, but I doubt many. It's probably a personality thing. If two people are so in sync that they can code without slowing each other down or getting in the way of each other thinking through complex ideas then they probably should be pair programming, but I just wonder how much of that really exists. I think many of us program at our best with a little solitude. Now, I do think "pair programming" can be beneficial with solving a particular problem but this is like something everyone should know just from life.
Keithamus 15y ago
One thing which the article didn't highlight, which I discovered when our team tried to switch to a 100% pair environment - the variable skill and speed of individuals. One of the biggest problems we had was developers getting frustrated inside their pairs, because one of the members of the pair was weaker in some way, either slower, less experienced at the product, or less skilled generally. Not only this but in a diverse environment with multiple cultures, where various disciplines vary, it managed to increase stress levels a lot also (as an anecdotal example, one of our colleagues was wound tightly and liked to be very procedural, while the rest of us were very laid back). These people all worked great on their own -- and got along -- but as soon as you pair them it all goes to shit.
trustfundbaby 15y ago
I have always found the idea of pair programming odd, because to wit, I don't know any other intellectually involved/creative endeavor that forces people to work in pairs like this. Even more fascinating is the absolute lack of data to show that pair programming does indeed improve group productivity (unless I missed it, please send me links if I have) On a personal level, I absolutely detest the very idea of fulltime pair programming, but I assume that its because of my personality. I hate it so much that when I was interviewing for gigs, the first thing I would ask is if they pair programmed, if they did, I'd politely remove myself from the running for that position with the company. I have my moods, sometimes I want to work for 18hrs straight, sometimes, not so much. Sometimes I want to go down a rabbit hole that I know is stupid, I just want to because its exciting to try out possibilities. I hate that pair programming would seem to preclude all that (again I might be wrong). I don't want to constantly be explaining why I'm doing something, it just seems tiring. It takes something I enjoy and turns it into 'work', where I'm just coding with someone, day in day out 8 hours a day. Good for the company I suppose. I'm sure people love it though, what would be an interesting statistic to see is how many devs would pair program if they didn't have to.
- cageface 15y ago
  I don't want to constantly be explaining why I'm doing something, it just seems tiring. This is my biggest objection to pairing. Usually when I'm first working on something new I don't really understand the problem so I'll slap together a very quick & dirty solution and then either refine it from there or toss it and start over. Being forced to slow down and verbalize my thought process at this stage just slows the process way down and makes me less willing to experiment. Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.
  - heretohelp 15y ago
    >Good code reviews seem to me to provide most of the upside of pair programming with none of the downside. Your suspicions are accurate. I can't find it right now, but I remember reading a thorough study on software and the bugs eliminated by various processes. It was code reviews (multiple variations of them, in fact) that stood head and shoulders above the rest in preventing bugs from reaching production.
Jach 15y ago
The only account of pair programming that made me spend time considering it was the story of Guy Steele pairing with Richard Stallman. My overall takeaway is to treat pairing like mind melding, and if you can't get your minds to meld it's going to be disastrous. From http://oreilly.com/openbook/freedom/ch06.html http://oreilly.com/openbook/freedom/ch06.html : "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."
greenyoda 15y ago
This article begins with the premise that Atul Gawande's insights may apply to programmers. However, Gawande's writing has dealt mostly with the work of people like surgeons (he's one) and airline pilots. There's a crucial difference between this kind of work and the work programmers do: surgeons and pilots have to get everything right in real time -- a very brief lapse in attention could lead to disastrous consequences. Programming is different: you can review code after it's been written and get the benefits of a second pair of eyes (or several extra pairs of eyes) examining it at leisure. So if pair programming makes a particular programmer more productive, that's fine, but if it makes other programmers less productive, no tragedy will result if they use code reviews instead. That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right: http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...
ralphos 15y ago
I think the conclusion he has is right. It's not appropriate to pair 100% of the time. Having said that if you look at the way Pivotal labs pair up, they have really strict rules about what's allowed on the 'floor' e.g. No laptops, no cellphones, no distractions. So while working alone can give you more privacy and space to become creative, unless you're really disciplined by yourself, pairing up can actually be beneficial in forcing you to become more productive. I think the other thing the author fails to mention is that in terms of up-skilling developers, the process of pairing is quite useful. Often the pairing will naturally raise the level of the weaker programmer by virtue of being exposed to new ideas and solutions by the more experienced developer.

46 points by Qwl 15y ago

The headline doesn't really reflect the article, though after all its waffling before getting to the point I don't think any of its conclusions are all that revolutionary. It comes down to this: when developing software in a team[1], you have conflicting requirements. Your programmers/designers need to communicate effectively enough with each other[2] to keep them pulling in the same direction, but you want to optimise individual productivity. The optimal balance will depend on the project, team size and of course the individuals involved. It will even fluctuate wildly throughout the project. So really, the best thing you can aim for is to create an environment that's flexible enough to adjust to a balance that is close enough to the optimum of the day. I'm disappointed anyone still believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. There is no substitute for common sense. Still, I was pleasantly surprised after my considerable initial trepidation about reading a programming article on TechCrunch. [1] or probably doing anything else creative, but I can't speak from experience [2] and, let's not forget, communicate with the actual users of the software

jackfoxy 15y ago

two coders at one keyboard... Pair programming without dual keyboards and mice deserves castigation.

derekp7 15y ago
Is there any good way to have two keyboards, two mice, both act semi independently? That is, I want two mouse pointers, and if mouse A clicks on a window, I want keyboard A bound to that same window; same with mouse B and keyboard B (and of course they can also each click on and be bound to the same window as needed). Preferably a Linux solution, but something on Windows would be OK also. What often happens, is someone would ask me to help them look at something, but they are multitasking multiple problems. Initially I can take over their keyboard & screen, but before long another call comes up and I have to transfer the problem / environment back to my desk, and get back to them (or end up owning the problem completely). I think having the keyboard & pointer independence combined with an editor that lets you have multiple windows attached to the same edit buffer (like Emacs) would be wonderful.
- dustineichler 15y ago
  You could try mirroring monitors.
  - derekp7 15y ago
    But in that case, both monitors are still tied to the same workspace, and only one window can be active at a time. I'm looking for a way to have two active windows, each with its own keyboard attached.
    - dustineichler 15y ago
      This might be worth a read. Tom Dale wrote about his setup. There's a reference to how Pivotal Labs is setup too. I prefer the later if you can afford it. http://tomdale.net/2012/01/tildes-pairing-setup/ http://tomdale.net/2012/01/tildes-pairing-setup/

suresk 15y ago

I really dislike paired programming, and if I ever end up in another situation where all or most of the day is spent sharing the keyboard with another developer, I think I'd go insane. My first experience with it [1] was pretty bad from both a happiness and productivity perspective. I've always thought that for the purpose of improving code quality and transferring knowledge, a formal code review process is much, much better. Indeed, I've always wished more development shops would utilize a code review process of some sort. 1. http://www.spenceruresk.com/2009/03/impaired-programming-how-neither-of-us-is-as-dumb-as-both-of-us/ http://www.spenceruresk.com/2009/03/impaired-programming-how...

pmjordan 15y ago
I find pair programming is useful for overcoming a specific problem, after which you have to disband and each go off on your own. Examples: - The problem can be that programmer A is stuck on a piece of code or debugging: this is usually part of a bigger task which A has as the top thing in their mind, but for some reason can't make progress. Programmer B brings a fresh pair of eyes to the table, but looking at it alone makes no sense, because their mental model will be up and running much faster with A's help. - Onboarding. Programmer B is new to the project and programmer A gives an increasingly hands-on crash course of the project workflow and B's first task. - The high-level parts of major refactorings. Neither A nor B will have the whole existing structure of the code completely in their heads, but between them they have a more complete picture and stand a much better chance of not messing it up. None of these should take more than a few hours, or maybe a day max, or you probably will go insane, yes. It probably also depends on personality, but you should hopefully not have any homicidal tendencies after just a few hours.
- suresk 15y ago
  Sorry, I should have worded that a little more carefully. Yes, I agree there are situations where a limited-duration pairing is useful and even ideal. It is only when pairing consumes most of your day for days or weeks on end that it gets really tiring and counter-productive.
  - 15y ago

MatthewPhillips 15y ago

Looking at a specific problem for a short period of time (10 minutes) with another competent programmer is one thing. But trying to concentrate with another person looking over your shoulder is aggravating. My experience is that you are more likely to take shortcuts to get the task over with. You don't want to do anything that is going to take real concentration because concentration is impossible when another person is likely to interrupt your thinking to converse. That is by far the worst part of pair programming. Knowing that your mind is free to explore a problem to whatever depth is necessary is absolutely critical to solving something non-trivial. I find it really hard to explain the damage of interruption to non-programmers. Whether it is a girlfriend or a client that likes to talk while you're fixing their bugs. I don't think it is necessarily unique to our profession, but it is certainly rare enough that most people seem not to get it.

dustineichler 15y ago

This [redacted] pisses me off, I'm sorry. Jon writes well, but I read the New Yorker article on "Group Think" which he references... in TechCrunch. I'm as shocked as you are. It's speaks well of individual creative process and how brainstorming and really other processes are bull crap. Technically speaking. If you think back, before Agile and other methodologies came along, developers were doing more with less than I'd consider any of us are doing now. For the most part. Pairing works, no doubt but I _hate_ how institutionalized it's become. I'd work at Pivotal if I could, but they pair 100% of the time. I consider myself an introvert, for the most part too. Pairing is painful if it's not organic. The article is inconsiderate article because it's speaks nothing to the fact that our profession was built on the backs of people who are socially awkward and enjoy privacy if not a certain level of autonomy.

jonstjohn 15y ago

The company that I currently work at uses pair programming extensively - not 100% but strives for 3 hours per day. Although I understand its value, actually doing pair programming can be exhausting and tedious. I've also found myself working twice as hard/fast during non-pairing hours b/c I knew that pairing would sometimes be painfully slow. Lately, I've tried to work productively with my pairing partner in tandem, rather than sitting in front of a monitor together 3 hours a day. I love the company that I work at, so I'm not likely to let pair programming dissuade me from staying there, but when if and when I do look for a new job (or start my own company), I would be very wary of a shop that uses pair programming extensively. I really love working in a team and directly with others on projects, but pair programming can be very tedious, particularly if there is a big gap in experience between the two people in the pair. We also use code reviews for all code that goes to production. I find this to be extremely valuable. For more complex pieces of code, we do 'design proposals' that are circulated within our small team (4 developers) to get feedback and improve the design of our code.

osivertsson 15y ago
Yes, it is my experience too that pair programming works best when you both are at roughly equal levels of experience and both really want to succeed with the task at hand. Code reviews in groups often work really good despite different levels of experience though. It is exhausting to do pair programming, but when it really does work the feeling of progress and mutual knowledge sharing is awesome. In these optimal cases me and my coworkers have worked in pairs for 5-6 hours per day. Pushing on for longer would not have gained anything, rather the opposite.
- AlisdairO 15y ago
  In support of pair programming with a knowledge disparity, I have to say I've found it a fantastic way of bringing new team members up to speed. Yes, it's a bit of a pain in that it can bring productivity down for a while, but I really feel that it has long-term benefits.
- mtts 15y ago
  I work with a lot of interns these days, doing what's essentially pair programming with them and I don't feel their lack of expertise brings me down at all. Instead, I find having to explain everything I do to them brings a clarity to my own mind that is difficult to obtain otherwise. Of course it does help that when my explanations truly fail, I still have the nuclear option (Hey, they pay me to teach you this stuff, so just believe me) available, but (I'd like to think) I only rarely use it.

lukev 15y ago

Off topic, but the "considered harmful" titling meme annoys me. Dijkstra gets a pass, but it's now become a passive, cliched, content-free, overused way to say you disagree with something.

tikhonj 15y ago
My first reaction upon reading the title was thinking of the essay "Considered Harmful” Essays Considered Harmful[1]. [1]: http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html And the quality of this article just proves the point, I think.
zeeed 15y ago
logging in to upvote parent. to me, tc has lost its journalistic credibility a while ago.
- tincholio 15y ago
  >tc has lost its journalistic credibility a while ago. Around the time it was founded, I'd say

mattiask 15y ago

I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increase general quality risk being offset by decreased productivity of the top performers. If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best. This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly. The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer. It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right. If you can manage it, hire really good developers and get out of their way.

skrebbel 15y ago
your entire point is based on that 10x productivity rule. it keeps popping up. Is it just someone's gut feeling turned into an urban myth or have real studies been done?
- 15y ago

pairing 15y ago

I pair 100 percent of the day so 8 hours a day for the last year. It has been a very rewarding process. As a natural introvert pairing has made me a much more communicative person and my programming ability has significantly leveled up as well. We pair with 2 monitors, 2 keyboards, and 2 mice facing each other with our own desks which I feel gives each person in the pair enough privacy and space to make us both very comfortable. Is pairing intense? Yep. Is it worth it? Absolutely in my mind. The high quality of the code and the productivity is well worth it.

dustineichler 15y ago
I'm glad you said that, but setups like yours are the exception not the rule. Last I was there, PL has the same. I'd mostly agree too it's a rewarding experience, but it needs to do done right. If you half ass the setup, it gets frustrating quickly.
- pairing 15y ago
  Agreed. We started the project at Pivotal so that is where we got the setup, and I agree that it makes a huge difference. It's a shame more companies don't implement pairing correctly. The extra grand (less if you don't go with an apple display) for the monitor is a small price for the results you get.
  - dustineichler 15y ago
    They're known for distilling culture and values on clients. It's apart of their high value-added proposition i think. e.g. - best practices.
pmjordan 15y ago
Do the screens display the same content, and do the input devices control the same cursor? I find this 2-desk pair programming a curious arrangement.
- pairing 15y ago

dinkumthinkum 15y ago

This is definitely YMMV territory. On the whole, I think a formal pair programming process is probably a bad idea. I wouldn't want to work somewhere where I had to play that game. Perhaps, that just means I would be a poor choice for such a company. :) However, I wonder how many of the "great" who's-who of programmers would have actually liked such a process; sure, you can find some examples, probably, but I doubt many. It's probably a personality thing. If two people are so in sync that they can code without slowing each other down or getting in the way of each other thinking through complex ideas then they probably should be pair programming, but I just wonder how much of that really exists. I think many of us program at our best with a little solitude. Now, I do think "pair programming" can be beneficial with solving a particular problem but this is like something everyone should know just from life.

Keithamus 15y ago

One thing which the article didn't highlight, which I discovered when our team tried to switch to a 100% pair environment - the variable skill and speed of individuals. One of the biggest problems we had was developers getting frustrated inside their pairs, because one of the members of the pair was weaker in some way, either slower, less experienced at the product, or less skilled generally. Not only this but in a diverse environment with multiple cultures, where various disciplines vary, it managed to increase stress levels a lot also (as an anecdotal example, one of our colleagues was wound tightly and liked to be very procedural, while the rest of us were very laid back). These people all worked great on their own -- and got along -- but as soon as you pair them it all goes to shit.

trustfundbaby 15y ago

I have always found the idea of pair programming odd, because to wit, I don't know any other intellectually involved/creative endeavor that forces people to work in pairs like this. Even more fascinating is the absolute lack of data to show that pair programming does indeed improve group productivity (unless I missed it, please send me links if I have) On a personal level, I absolutely detest the very idea of fulltime pair programming, but I assume that its because of my personality. I hate it so much that when I was interviewing for gigs, the first thing I would ask is if they pair programmed, if they did, I'd politely remove myself from the running for that position with the company. I have my moods, sometimes I want to work for 18hrs straight, sometimes, not so much. Sometimes I want to go down a rabbit hole that I know is stupid, I just want to because its exciting to try out possibilities. I hate that pair programming would seem to preclude all that (again I might be wrong). I don't want to constantly be explaining why I'm doing something, it just seems tiring. It takes something I enjoy and turns it into 'work', where I'm just coding with someone, day in day out 8 hours a day. Good for the company I suppose. I'm sure people love it though, what would be an interesting statistic to see is how many devs would pair program if they didn't have to.

cageface 15y ago
I don't want to constantly be explaining why I'm doing something, it just seems tiring. This is my biggest objection to pairing. Usually when I'm first working on something new I don't really understand the problem so I'll slap together a very quick & dirty solution and then either refine it from there or toss it and start over. Being forced to slow down and verbalize my thought process at this stage just slows the process way down and makes me less willing to experiment. Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.
- heretohelp 15y ago
  >Good code reviews seem to me to provide most of the upside of pair programming with none of the downside. Your suspicions are accurate. I can't find it right now, but I remember reading a thorough study on software and the bugs eliminated by various processes. It was code reviews (multiple variations of them, in fact) that stood head and shoulders above the rest in preventing bugs from reaching production.

Jach 15y ago

The only account of pair programming that made me spend time considering it was the story of Guy Steele pairing with Richard Stallman. My overall takeaway is to treat pairing like mind melding, and if you can't get your minds to meld it's going to be disastrous. From http://oreilly.com/openbook/freedom/ch06.html http://oreilly.com/openbook/freedom/ch06.html : "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."

greenyoda 15y ago

This article begins with the premise that Atul Gawande's insights may apply to programmers. However, Gawande's writing has dealt mostly with the work of people like surgeons (he's one) and airline pilots. There's a crucial difference between this kind of work and the work programmers do: surgeons and pilots have to get everything right in real time -- a very brief lapse in attention could lead to disastrous consequences. Programming is different: you can review code after it's been written and get the benefits of a second pair of eyes (or several extra pairs of eyes) examining it at leisure. So if pair programming makes a particular programmer more productive, that's fine, but if it makes other programmers less productive, no tragedy will result if they use code reviews instead. That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right: http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...

ralphos 15y ago

I think the conclusion he has is right. It's not appropriate to pair 100% of the time. Having said that if you look at the way Pivotal labs pair up, they have really strict rules about what's allowed on the 'floor' e.g. No laptops, no cellphones, no distractions. So while working alone can give you more privacy and space to become creative, unless you're really disciplined by yourself, pairing up can actually be beneficial in forcing you to become more productive. I think the other thing the author fails to mention is that in terms of up-skilling developers, the process of pairing is quite useful. Often the pairing will naturally raise the level of the weaker programmer by virtue of being exposed to new ideas and solutions by the more experienced developer.