Why Pair Programming Is Not For the Masses
blog.obiefernandez.com
blog.obiefernandez.com
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!"
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.
In a healthy environment, I prefer pairing, for most of the same reasons that are described in the NYT article. But it's not for everyone any more than red crewneck shirts are for everyone.
The more effective the communication the better the software. If two teams don't work well together, that is reflected in the software.
No matter how long you've been programming solo, you can't expect to sit down with a pair and have it "just work". Sure, it happens sometimes, but if it doesn't, you should practice it a bit before discounting the idea.
There are a few things the navigator can do to help out the driver while the driver is typing, but I hesitate to focus on them. In general, both programmers should be engaged. Learn to talk out ideas with your pair in short segments.
TDD helps. Test driving code naturally gives your pair many opportunities to inject their ideas without ruining your train of thought (ie: stop and discuss things at least after every test, preferably much more, but that comes with practice).
It took working with talented pair-programmers at ThoughtWorks to really make it click.
Revealing sentence.
You "had a large measure of doubt about its effectiveness" but since you were a "zealous advocate" (of something you were doubtful about!) you mostly "kept the faith".
Sounds pretty hypocritical and manipulative. How are we to believe your "zealous" declarations now?
No wonder agilists are often dismissed as "One True Way" religious fanatics.
When someone doesn't experience the unbridled joy of pair programming salvation, it is always something wrong with them, their task, or their partner. Essentially, "oh you weren't pairing correctly" -> "you didn't have enough faith".
Is there any possibility pair programming advocates can cede that developers can eschew pair programming and still produce quality code?
If you are pair programming either by choice or circumstance, it's useful to know some tricks to make it work better. But if you've tried it and don't think it's the right thing, then you should do something else.
How you organize a team is up to you, but pair programming does remain a highly effective tool for some teams. It certainly beats change control boards.
When I pair I'm having an active discussion with the person I'm pairing with about what piece of functionality we're implementing. We don't rubber-stamp things for the sake of it.
If my pair has a great idea on how to do something and I don't, I let them run with it, and then maybe I have an idea that builds on top of that, which I may not have figured out on my own. I'm analysing what they're doing, thinking of ways to improve it as they go.
This idea of one person just coding away while the other person sits there is a mystery to me. If one person is 'passive', you're doing it wrong.
Really? In this context, I find that I'm the one who often says, "will someone understand what this is doing when they see it the first time?" When it's just me, I may not stop to consider that POV.
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.
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?
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.
You should have provided some flimsy anecdote, though, just to complete the emulation.
Pair programming doesn't work for everyone not because of those pretty dumb reasons. Pair programming doesn't work for everyone because not everyone is the same in their thought processes. Personally, I'm a very outgoing guy and when working with a team on a problem I love to throw ideas around and, if I'm the more knowledgeable one of the group, teach. But I know for sure that some people would rather work alone on a problem, and if that's what gets a problem done quicker and more efficiently, power to that person!
I was hoping this article would dive into the more social aspects of pair programming, but nope. Instead it was "your hardware sucks" or "your company sucks".
I would say "Pair programming? Yo, Obie, I already gotta pair!" in my best Andrew Dice Clay manner -- but with a German accent, my best Andrew Dice Clay manner is rather abysmal...
Hmm. Andrew "Würfel" Klay could sound interesting ...
The "holier-than-thou sense" is a major detriment to successful pair programming, as it is to any form of collaboration.
The mediocrity that surrounds a good programmer at a typical enterprise level shop is astounding. It surprises me that they allow some of the people to continue working there! There are a LOT of people out there that got into programming as a way to pay the bills and for those people, pair programming would probably be like torture.
Or go into management. Do they practice Pair Leadership? Didn't think so.
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.
http://www.nytimes.com/2009/09/20/jobs/20pre.html
working hard != being over-worked ... at least that's how I understood it
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.
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.
pairing means sharing thoughts, means thorough examination of thoughts, means validated thoughts, means code based on good reasoning.
[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
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.
What ever happened to hiring good people and training them?
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?"
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.
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.
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.
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 (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.
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.
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".
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...
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).
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.
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.
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.
The burnout objection is laughable. Our consultants are required to bill 35 hours per week, which translates to an average of 7 hours of coding or less every day (there is billable work like meetings that is not writing production code).
We don't work weekends and we don't do overtime. Like, ever.
That being said, you've made it clear that your entire team already fits your style, right down to having the same preferences in breath odour. I wonder though how much productivity is lost managing that aspect of things. :-)
The reason, for me, was that at the end of a work day I went home feeling like I had actually DONE something of value that day. I felt that way every day. It felt good. By feeling good about what I had done I felt much less like I needed to work at night. I felt that I had "earned" some relaxing time away from work.
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.
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.
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.
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.
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
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.
So in order to pair effectively, everyone has to use the same tools. And that's going to be a big problem for people who don't like those tools. I don't think the article really hit that point.
EDIT: Oh and your little aside: 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 is fabulous. Love it.
Flow is a very important part of pair programming.
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.
Kent Beck = Jim Jones. Beware.
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.
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.
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.
Personally I think pair programming is overrated while code review is still underrated.
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...
You write: "most of the people who have tried pair programming like it". Your conclusion is contrary to one of the the article.
pair programming intends to prevent rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.
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.
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.