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.
Where Pair Programming Fails for Me
11–20 of 41 posts
Re: Where Pair Programming Fails for Me
#12Earlier quoted context omitted.
> First, pair programming has to be between near-equals, or it just doesn't work. That depends on what you think the goal of pair programming is. > If one person knows a lot more than the other, most of the time is spent in training. Which is part of the intended effect of pair programming. It forces everyone to share their knowledge with everyone else both about programming, and about the code base. This brings new…
I agree. To the GP's point though, they still weren't doing effective pairing for the 'training' or 'coaching' scenario. The pairing was contentious and out of balance. The coach didn't do any coaching. > ...if I paused too long, or seemed to be typing the wrong thing -- my pair had another keyboard, and he would type over me to try to “finish the sentence” rather than talk to me. In this case, a coach should engage…
> Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high.
And once tests are passing, you should be able to convince your partner the code isn't dry simply by pointing out duplication, preferably 3 or 4 instances of it so you have enough examples to generalize a solution. You don't need tests to convince him something needs done.
Re: Where Pair Programming Fails for Me
#13This guy describes a really common antipattern I've seen with pair-programmers, call it "Workstation Chain Gang". This is where all work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating.
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.
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!
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.
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.
Re: Where Pair Programming Fails for Me
#14I think the author is conflating Pair Programming with other concepts.
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. ...
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. ...
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. ...
What on earth does any of that have to do with Pair Programming?
Re: Where Pair Programming Fails for Me
#15No one should have to suffer what this particular man suffered. Holy crap that's depressing.
His experiences with pair programming parallel my own. I had to quit an otherwise fun job, that paid really well, because I simply could not stand being that close to other people for that much of the day.
Re: Where Pair Programming Fails for Me
#16I think the author is conflating Pair Programming with other concepts. 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. ... Eventually, I realized that many of my partners had never…
It sounds like his biggest beef is the lack of refactoring that supposed to happen after the tests pass.
Red, Green, Refactor.
Re: Where Pair Programming Fails for Me
#17What a fucking nightmare.
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.
Re: Where Pair Programming Fails for Me
#18My 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.
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.
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:
Reducing defects? Code-reviews.
Over engineering? Design documents.
New hires? People switching projects? Assign a mentor for a week or so and have them pair-program.
Faster debugging? Understand that it is OK to ask a colleague for help.
Re: Where Pair Programming Fails for Me
#19I 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.
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.
In short. pair programming only works for me if I am surrounded by "yes men".
Re: Where Pair Programming Fails for Me
#20I got to the point where the other person started typing when it wasn't their turn. 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. 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…
This seems like a common excuse I see to criticisms of pair programming. If this technique is so fragile, perhaps its just better to admit up front that it is delicate and easy to get wrong, and only works in particular situations with particular people.
"If it failed then, there's no reason to think we can't make it fail now." -- Colin Benson, in the IMPP working group, circa 2000