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.
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.
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.
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.
My experience is that pair programming works almost as well when one of the pair is virtual, or time-shifted [i.e.: code review or review rehearsal]. And it's much more efficient.
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.
At TIM Group, I've followed the advice in your last sentence by hiring the very best developers I could possibly find and imposing minimal "management overhead". Interestingly, at some point they tried pairing, and decided it made them much _more_ productive; they continue to use it extensively even though it is not at all required (these days it is a cultural norm, but not dictated practise).
Just a single experience - a proper academic study would be very interesting if someone could manage it - but it doesn't seem to match your theory.
I'm sure there are developer pairings and scenarios where pair programming indeed would be beneficial. The point is that in your case the developers where free to themselves test and evaluate it's efficiency and then chose whether to use it. If that's the case then of course you should go with pair programming. That's different however from mandating pair programming where they'd have to use it whether or not it fitted them personally or that the pairing worked out.
My point is not as much about specific practices but rather about mandatory ones.
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?
"Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and performance. (I doubt if that is universally true.)"
The 10x comes from the fact that you have 10 fingers. The real number is going to depend wildly upon the context. I've been on projects in which some members contributed zero--and so the ratio is NaNx. On the other hand, if you're writing COBOL crud, the fastest typist will typically be the most productive.
I've been on projects (and I'm sure I'm not alone in this) in which some members contributed negative value.
To contribute zero a bad programmer would have to just sit around and reddit all day or whatever. Once the bad programmer starts writing code he is almost surely a net negative since eventually someone is going to have to rewrite his code and unless the code is completely decoupled from everything else, the time required to do that rewrite will exceed the time it would have taken if the bad programmer had never written any code at all.
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.
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.
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.
FWIW, I agree with you about code reviews. I'd add that I've found in-person code reviews to be the most helpful from a communication point of view. For remote teams I suspect live screen sharing with audio is a reasonable substitute. I guess the downside compared to a formal annotated code review is that the latter is a kind of documentation. Not that I've ever referred back to one, but it's conceivable.
This is a good insight. Pair programming is a tool that is very useful in some contexts but not in others.
There are so many things that can vary from project to project: How big is the system? What level of expertise does each developer have with the domain, or with the tools being used to build it? What are the personalities of all the people involved? Is the system a cutting edge research project or a well understood thing that just doesn't happen to exist yet?
All of these variables, and lots more, would influence my decisions about who I'd want to work with, and (if there is someone other than me) how we'd work together.
Given all that I consider it extremely unlikely that there are any useful and universal conclusions to be drawn.
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.
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.
>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.
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.
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
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.
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:
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.
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 :
"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."
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.
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.
Exactly, one monitor is an iMac the other is a thunderbolt display. The display just mirrors the iMac. We each have our own keyboard and mouse which controls a single cursor. The monitors face opposite each other so we are sitting (almost) directly face to face so talking to each other is natural with minimal turning, which would occur if you sat next to each other.
Interesting. I have a feeling this would drive me insane in the long run. Is there a particular problem you're attacking with this arrangement? Did you try a different approach before that didn't work so well?
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.
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.
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.
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.
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.
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.
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.