This guy describes a really common antipattern I've seen with pair-programmers, call it "Workstation Chain Gang". This is where <i>all</i> work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating.<p>The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to read about this. Let's get back together in half an hour." Or even say, "I need some alone time" They attend to their own needs along with the needs of their pair. This can take a lot of personal courage and honesty sometimes, and requires an environment that encourages attending to yourself.<p>This guy sounds like he felt like he needed to put on a continuous show for his partner, and that was really hard for him. Which it is!<p>I bet he was right that he had to be constantly chained to the workstation. The "eight-week sprint" sounds like a pretty awful slog, especially with the set-in-stone up-front design. Overall, it sounded like a lousy, poorly managed setup.<p>Its too bad that he associated it with pair programming particularly, but oh well. There's many ways of working in the world, and it sounds like he's happier now.
I've pair programmed quite sucessfuly for several years. However, it is a very hard practice. It requires trust between people, first and foremost. Besides that, it requires knowledge that you can't do it all day. It is too intense and tiresome, and this lack of slack is bad for creative thinking. About the pride: it is like co-foundind a startup, where you build something toguether with other people (it is all yours).<p>Some other links:<p>- Dijkstra Pair Programming: <a href="http://c2.com/cgi/wiki?DijkstraPairProgramming" rel="nofollow">http://c2.com/cgi/wiki?DijkstraPairProgramming</a><p>- Some notes on Pair Programming <a href="http://wp.me/puh71-1y" rel="nofollow">http://wp.me/puh71-1y</a><p>- How Pair Programming Really Works: <a href="http://bit.ly/5oOd4C" rel="nofollow">http://bit.ly/5oOd4C</a><p>- Why I Don't Like Pair Programming (and Why I Left Pivotal): <a href="http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html" rel="nofollow">http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-pro...</a><p>- The real motivation behind pair programming: <a href="http://bit.ly/9DNurb" rel="nofollow">http://bit.ly/9DNurb</a>
What a fucking nightmare.<p>Whether what he did was or was not Official Pair Programming (tm) is beside the point. Obviously, some people will thrive having to interact with a partner all day, every day, while others will wither. Requiring all your developers to work in this style is just nuts. It's like requiring all your developers to wear size 31 jeans.
"And if I was writing code, I found something very interesting: I don’t think in English when I write code. I think in code first, and I can translate written code to English. When I was trying to talk to people when I was writing code, I found that I’d have to write pseudocode and then talk to them about it -- and when my pair wanted me to talk about code, he wanted me to stop typing. But if I stopped typing, I couldn’t describe what I was doing. <i>Every time I tried to write code and talk to my partner at the same time, I could feel the lurch between what I could feel -- the complex shape of it in my head -- and what I was having to say.</i>"<p>(emphasis mine). What an incredibly familiar description. Does anyone else ever feel this way? This is why in situations where I'm trying to describe a solution I end up just grabbing the keyboard, doing it myself, and letting the code talk for itself.<p>For me, pair programming comes easily when describing a solution that can be simply defined and understood. Doesn't matter how difficult the problem itself is. Pair programming becomes more difficult once you have to interrupt your coding to facilitate the process. As an introvert, this comes incredibly unnaturally to me.
Great article. I like to see people giving a detailed critical response about a practice which has increasingly become a kind of "Politically Correct" element in software development. Must always write units tests, for everything, and first -- hallelujah! Must pair program -- praise be thy name, thou art in heaven!<p>My own take: if it works well, do it. If it doesn't, do something else. Repeat. But your bottlenecks in the larger world tend to be talent, time and cash (though the latter is becoming less so in software development). If you have (enough of) those, use them and ship, get profitable, and anything procedural or paradigmatic should be far down your list of priorities.
This matches my experience as well.<p>Like most things advocated by XP people, pair programming is simply soul crushing and meant to replace skill and experience ("I know it's not the simplest thing that could possibly work but my experience tells me we'll be needing this later") with mindless repetition.<p>Very much like religion.<p>Thanks, but no thanks.
I hate pair programming. I find a lot of the times my partners are distracting me with a forgotten semicolon while I have already added that to my queue while my fingers are racing along.<p>On the other hand having to justify an idea to someone else (provided they are non-contentious, but really trying to analyze things) is worth its weight in gold.<p>In short. pair programming only works for me if I am surrounded by "yes men".
I got to the point where the other person started typing when it wasn't their turn.<p>First, pair programming has to be between near-equals, or it just doesn't work. If one person knows a lot more than the other, most of the time is spent in training.<p>Second, if the other person just starts typing, it isn't really pair programming. It's what we call 'peer programming' where you peer over someone's shoulder and they do all the work.<p>'Peer programming' happens a lot with mis-matched skill levels.<p>I didn't read the rest, but I assume it's all as much a bastardization of Pair Programming as the first bit.<p>PP didn't fail you. Your coworkers weren't using it.
My view is that pair-programming is a tool which only really works for stuff dealing with tactical decision making, logic/fact checking, teaching or debugging.<p>Higher level abstract stuff which involves creativity (design) or strategic decisions won't work because there is no process for these activities. You can't synchronize (communicate) where you are on your way to the "eureka" moment. Discussing with others certainly helps but there nothing pair-programming specific about it.<p>Also, don't forget that most, if not all, of the assumed benefits of pair-programming can be gained using a more flexible common sense approach:<p>Reducing defects?
Code-reviews.<p>Over engineering?
Design documents.<p>New hires? People switching projects?
Assign a mentor for a week or so and have them pair-program.<p>Faster debugging?
Understand that it is OK to ask a colleague for help.
I don't have any experience with Pair Programming as it is typically prescribed by "agile" project managers, but from my understanding of Pair Programming, I believe that there are more cases like this where Pair Programming doesn't work than there are cases where it does work.<p>I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I do not have experience working on an "agile" team doing every day pair programming. There are a lot of job descriptions that back this issue up.<p>I learned Ruby on Rails on my own and have successfully developed and deployed two significant applications during my spare time using Ruby on Rails in the last 3 years. The applications I've written are not open source and they are not public access sites, and until I do get something written within the public facing / open source realm, I am convinced that I probably won't ever get considered for a full time rails job.<p>I've mostly just about given up on ever expecting to get hired by a company that uses Ruby on Rails. It is all total bullshit in my opinion. I will continue to use Ruby on Rails on my own and ignore Pair Programming because I see Pair Programming as a form of micromanagement and not an opportunity for programming productivity.<p>I have plenty of experience working with other software developers on the same piece of code, in front of the same terminal window, for two or three hours at a time - always initiated by myself or the other developer, not prescribed by management. The fact that I don't do it every day is irrelevant in my opinion.
After a few months of pair programming, I can only agree. At points, when my partner saw a better way of doing things, it was insightful. In the end, however, we found that it was more efficient to split up the work, merging code when necessary.
I generally like pair programming in some cases, and dislike it in others.<p>You have to combine it with TDD or else each person focuses on something different, and basically reverts to being a spelling mistake checker until it is their turn.<p>I have only enjoyed it when doing mostly new development, in a modern language with modern tools, combined with a strict red green refactor process, where one person writes the test , and the next makes it pass and writes the next test.<p>For more exploratory stuff, or doing it without TDD, or using old crappy languages and tools, or doing maintenance, it just sucks and I prefer to work alone.
In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time.<p>I basically believe that crunch time increases the probability of errors by orders of magnitude. Secondly, as the author mentions, that is the time when gaps in knowledge need to bridged over... at the expense of personal ego if need be.
I think the author is conflating Pair Programming with other concepts.<p><i>There are no high notes, no thought out design. There’s only the design that could have tests written for it, in the time you had to write the tests. The classes look reasonable at first glance, and the methods are seemingly bug free. But the cracks are there, if you know where to look.</i> ...<p><i>Eventually, I realized that many of my partners had never worked outside a test driven development process: they didn’t have the same idea of design or architecture as patterns distinct from code. Trying to argue for encapsulation or adherence to SOLID principles is pointless if your partner has no background, let alone hands on experience, with what you’re saying. This goes double when you’re talking about hard-won domain expertise: the more I knew about a subject, the less I could say.</i> ...<p><i>The large part of pair programming was doing things in “The Simplest Possible Way That Could Work.” In practice, this meant doing it the way that it had been done previously, with the least possible amount of change.</i> ...<p>What on earth does any of that have to do with Pair Programming?
I've had good experiences with pair programming. This does not sound like my experiences and I feel for the writer. It sounds like a horrible situation to have lived through.