Why Pair Programming Is Not For the Masses(blog.obiefernandez.com)
blog.obiefernandez.com
Why Pair Programming Is Not For the Masses
http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html
107 comments
Some replies to your comment demonstrate exactly why I'm not a fan of forced pairing advocacy and the arguments they use. It borders on the religious: "I love pair programming. Try it, you will love it too"
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?
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?
Since I wrote one of the "here's how you could fix your pair programming" replies, I should clarify that I don't think pair programming is the only way to work. I'm not doing it in my job right now and don't particularly think I should be.
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.
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.
I see what you're saying, and I agree to an extent, so i hop my comment didn't sound religious. All I meant was, if someone is typing, and someone else is watching, and no one is talking, then you aren't doing what any reasonable person would call "pairing".
Don't dislike practices because there are people who are passionate about them.
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.
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.
Pairing is a skill, like programming.
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).
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).
Absolutely. It took me four years of misstarts and agony (2000-2004) to really understand and get good at pair programming. During that time I mostly kept the faith about it since I was a zealous XP advocate, but had a large measure of doubt about its true effectiveness.
It took working with talented pair-programmers at ThoughtWorks to really make it click.
It took working with talented pair-programmers at ThoughtWorks to really make it click.
"During that time I mostly kept the faith about it since I was a zealous XP advocate, but had a large measure of doubt about its true effectiveness."
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.
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.
[deleted]
If you find one person being "passive" in a pair session, you can switch drivers, so the person at the keyboard and the person who wrote most of the code so far are different. Or you can try something like the TDD Game (or any other format where one person writes tests or tries to break the code as the other writes it): http://www.peterprovost.org/blog/post/The-Pair-Programming-T...
What kind of code was that? It sounds like churning out boilerplate stuff in flow state. The passive one should be able to join to debug failing unit tests and to listen to your thoughts.
I pair program every day, and this is not a typical experience for me.
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.
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.
Pairing has helped me and my code a lot but as with most things there is a learning curve. Only an atrocious pair would say something like "Oh... yes, that function... I already thought of that, and here's why it can't work.". When pairing, thinking is talking. If the one not typing at the moment is allowed to get bored, then the pairing is not done correctly.
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.
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.
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!"
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.
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.
Equally you could point to numerous systems not developed using any form of peer review and conclude the opposite. In the matter of fact there's probably more bad systems hacked together by solo programmers than there are written by communicative teams.
There's probably more systems hacked together by solo programmers than there are written by communicative teams.
Systems that have no review of any kind are normally the ones that fail. Whether you are pairing or submitting to opensource where your code is checked, the quality goes up because things are checked.
The more effective the communication the better the software. If two teams don't work well together, that is reflected in the software.
The more effective the communication the better the software. If two teams don't work well together, that is reflected in the software.
I think you didn't have the type of pair programming experience which is described in the article. I've long ceased being a vocal advocate of pair programming, but when done well, you're having an ongoing dialogue with your pair partner. If the code isn't amenable to working that way, or if you or your partner aren't amenable to working that way (i.e., thinking out loud almost constantly), then it's probably a poor choice for you and your group.
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.
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.
Wow, that's one arrogant piece of writing. That still doesn't provide any good, scientific reason why pair programming is that much better -- yay for anecdotes.
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.
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.
It sounds like you just didn't understand what he was trying to say.
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?
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?
Wow, way to be hostile. These two were raising valid points in which I agree with. The article really does seem to have an attitude to it. He could have raised his point with implying almost every time that "my company is better than everybody else" kind of tone. Bear in mind that I'm not against pair programming, in fact, I want to experience that some time in my career (unless narcolepsy kicks in after being passive for so long).
I was lampooning the arguments of the article.
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.
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.
Don't worry, I didn't feel offended. If I make a mistake, it's mostly assuming sarcasm in stuff that's meant in a serious way, not the other way 'round.
You should have provided some flimsy anecdote, though, just to complete the emulation.
You should have provided some flimsy anecdote, though, just to complete the emulation.
Not to speak for roc, but I believe the comment was intentionally written in the style of the original article, probably to mock it.
FWIW, I believe the comment you replied to was satire.
oh. then I apologize for the reply if that was the original intention. Haha.
[deleted]
I too certainly got this holier-than-thou sense from reading the article, and I also felt that it missed the point.
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".
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".
Apart from the fact that we're still missing a serious study of pair programming (isolated from other Agile hooplah), it's also a false dichotomy. Isolated damsel programmer in the ivory cubicle vs. paired mind meld.
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...
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...
"but with a German accent, my best Andrew Dice Clay manner is rather abysmal..."
Hmm. Andrew "Würfel" Klay could sound interesting ...
Hmm. Andrew "Würfel" Klay could sound interesting ...
I always get the "this is why you should call us up" sales pitch vibe from Obie's writing
I too certainly got this holier-than-thou sense from reading the article, and I also felt that it missed the point.
The "holier-than-thou sense" is a major detriment to successful pair programming, as it is to any form of collaboration.
The "holier-than-thou sense" is a major detriment to successful pair programming, as it is to any form of collaboration.
Maybe I'm blind but I really don't see too much arrogance here. He is admitting that pair programming does NOT work for everyone and the reasons he gives are, to me, compelling and true. He's not evangelizing pair programming as a magic bullet for everyone.
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.
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.
I was thinking the same thing. This is just what the Rails community needs - another imperious douchebag.
Actually, I find that arrogance itself is the most important factor that prevents good pair programming. This is also anecdotal -- please excuse me for the lack of well funded studies. But I find it best to concentrate on good communication. Getting hung up on the (perceived) slowness or lesser ability of the other programmer brings suboptimal results.
"I find it best when I put a guard with a whip near each programmer. They work faster , more eager to stay long hours, produce on average x2 more lines of code. They should not forget that only 100 years ago their forefathers were working 18 hours in Manchester assembly lines factories. They should know that although it's a 21 century, the system has not changed"
I, for one, get higher quality work done when I'm allowed to take breaks. This shop might be heaven for workaholics, but there's a lot of really excellent folks who just wouldn't enjoy their jobs if there was someone in the room constantly pushing them to keep working. It's great their culture works for some, but if this were the norm - I'd quit my job and go back to school in something that didn't involve computers, very quickly.
Or go into management. Do they practice Pair Leadership? Didn't think so.
Or go into management. Do they practice Pair Leadership? Didn't think so.
Yeah, I had this experience at my last full-time gig; our IT director and the other IT person had no concept of the importance of resting your mind in the middle of the day (along with many other important things).
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.
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.
Actually, if you read the NYT article, they use a pomodoro time management technique–25 mins on, then a 5 min break.
http://www.nytimes.com/2009/09/20/jobs/20pre.html
working hard != being over-worked ... at least that's how I understood it
http://www.nytimes.com/2009/09/20/jobs/20pre.html
working hard != being over-worked ... at least that's how I understood it
The Pomodoro technique is phenomenal. I actually end up doing ~50 and 10 rather than ~25 and 5. The trick is, when the buzzer goes off, I hit save, mash make && make test and go grab a cigarette. Chat about the weather, video games, anything really with other folks (non-smokers are encouraged to take "smoke breaks" outside, get some much needed sunlight and just relax out of the cubicles). Come back in, look at compiler output or test results and there's a list of things to start working on. If it all ran fine, continue working.
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.
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.
I'm completely and utterly unconvinced that two brilliant programmers can produce more than twice their usual individual output together, versus just consulting when they have an interesting question or a stumbling block.
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.
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.
I've never tried pair programming so I don't have an opinion on it, but I do know of an interesting pair programming story about Richard Stallman. It's related by Sam Williams in chapter six of his book Free As In Freedom: Richard Stallman's Crusade For Free Software:
[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.
[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.
I don't know if LT and RMS would have gotten along in that way, but how productive over the years has each one been? If you put them on the same team and paid them well, and they had goals they shared, etc., etc., I don't find it all that unlikely.
> Hashrocket is a boutique shop, so we can be very picky about who we hire. [snip] We've hired qualified interns, but we don't hire apprentice or junior-level folks.
What ever happened to hiring good people and training them?
What ever happened to hiring good people and training them?
It's hard to do that on a client's dime, at least for me. (I know other consultancies do it all the time and it disgusts me.)
Part of running a business is paying the associated costs. Training new employees is an expected cost of running a business, so take it out of your end. Doesn't seem like a particularly outrageous idea...
It seems like pair programming is quite popular with consulting companies (Hashrocket, Pivotal). You get to charge for the time of two developers instead of just one.
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?"
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?"
You have spotted it.
The whole Agile movement and its practices, like pair programming, are driven and promoted by consultants who make money out of it.
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.
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.
Ugh. What a horrible article. I've done mandated pair programming in the past and I've had good and bad experiences during that time - it depends a lot on who your partner is and what the project is - there's no way it can be "the one true answer" with so many variables. My opinion is that pair programming is something that good developers do naturally when and for as long as is required. Mandating it for all development sends the signal that you think your programmers are too incompetent/stupid to trust on their own.
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.
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.
I fail to see in that article where it advocates mandated pair programming... In fact I think it does a pretty good job of pointing out when/where pair programming does NOT work (i.e. many environments for the reasons listed). If you happen to work in an environment not conducive to pair programming and they force you to do it... well then...
Pair programming to me is a managerial gimmick to keep trench people in check, like those timesheets with specifics down to five minutes. To make them look over each others shoulder, and not surf the web. To address the near-universal management suspicion that your employees slack on the company time. (Disclaimer: yes I did read that book about the (failed) Chrysler project experience generalization to whole industry, so am familiar with the official hype part).
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.
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.
Perhaps programming isn't really for the masses, many of these points just describe traits in people that cause bad software to be written period.
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.
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.
> "When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice."
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.
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.
The rigidity of this approach surprises me. I certainly think pair programming has value. But I don't understand why this company would be so rigid in enforcing it as the only way to develop software.
"The rigidity of this approach surprises me"
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".
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".
I think you're looking at it the wrong way. Instead of people being forced to pair, they get to pair. It doesn't seem unreasonable to me that they'd hire people that want to work the way Hashrocket works.
I've only ever had exceptional experiences when pair programming. Maybe it's for reasons similar to Obie's; the people that I paired with were excellent programmers.
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 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...
To the average programmer, having to pair full-time means they won't get to waste time during the day on [..] Hacker News.
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).
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).
Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out.
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.
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.
I think critics tend to compare pair programming to those moments when they are most productive. One programmer in flow may be able to really crank something cool out in a day or so. He might even work 25 hours straight to do it, and really get it out there. If he spends the next week polishing, tweaking, and adding very little functionality, he doesn't include that in his comparison to pair programming. He did it in 25 hours, it took a pair of programmers three days, the pairs are slower, even though the pairs are done and have moved on to other, important stuff.
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.
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.
> 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.
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.
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.
Bravo!
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.
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.
Only one form of burnout comes from long hours though. It can also come from repetitive tasks that require little thought, or in your particular case, being forced to approach problems in a rigid manner that isn't in your natural style.
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. :-)
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. :-)
When I tried it for a week I know I didn't feel burnt out. In fact I felt more alive and less tired than I had in years doing shitty waterfall work at IBM.
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.
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.
One week of anything is rarely enough to burn out.
Pair programming is an attempt to take two good programmers and turn them into one great programmer. If you hire great programmers in the first place, it is unnecessary and wasteful.
That depends on the difficult of what they're developing.
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.
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.
Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness.
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.
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.
Depressing but accurate reading.
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.
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.
I think pairing sucks. Based on my personal experience with it. I'm just not cut out for it, mostly. I'm more comfortable and productive in the the "private office with a door" environment that DeMarco and Spolsky advocate. I don't dispute that pairing works for some people, in some situations.
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.
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.
You've apparently been thrown off course by the love-it-or-loathe it reaction to pairing, but you're actually agreeing with the article. He's listing why it isn't feasible for most situations. (Though most people seem to interpret this as reverse psychology, though 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).
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:
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.
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.
Oh your reply just crystalized one of the main problems I had with pairing. See, I use emacs and a bunch of command line tools. Almost everyone else in the shop used visual studio. I think one other guy used some editor he liked. So to pair with someone I had to use visual studio, which is like asking a master carpenter to use a hammer and saw that were picked up at Wal-Mart instead of the tools he had spent a decade mastering.
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.
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.
Pair programming works. However, I don't see the point in using it all the time - in some situations, it's only as effective as working solo. It really rocks for crisis situations (pair debugging) or new feature implementation quickly (all-night coding).
Flow is a very important part of pair programming.
Flow is a very important part of pair programming.
I've tried pair programming a few times at several companies, and while it's occasionally been great to work through a specific problem, in general I wasn't a fan, it was awkward and boring. But recently, at my startup, I've been sitting on the couch coding on the TV (because I switched over to iPhone development and the only spare mac was the TV mac mini, and it can't drive my 30 inch monitor.) Pair programming has actually been happening fluidly with this set up, and it's been great. It's comfortable to sit side by side and both have a head-on view of the large monitor.
Let me get this straight. Did he just claim that managers need to be willing to fire someone for having bad breath? And he has the nerve to accuse others of tolerating anti-social behavior?
pair programming went out of fashion for the same reason foosball tables in the office did: it was a dumb idea somebody concocted in the haze of the dotcom boom. reality eventually reasserted itself, we grew up, and learned to work like professionals.
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.
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.
I just want to point out that saying "You're doing it wrong" (as the article does) does not necessarily imply that you could be doing it right. It doesn't have to be taken as a condemnation of your skills/ability. It simply won't work in all situations and the article does a pretty good job of pointing out blockers to pairing working.
[deleted]
Pair programming seems like one of those necessary evils. I don't find working with a partner any fun in terms of the joy of hacking stuff out and figuring stuff out on your own, but I see the value in having multiple eyes on code, and I'm sure it could have found lots of bugs in my past.
Yes, arrogant and absurd. It does prove one thing (yet again). Beware of Methodology Cults. That's what Agile and 'XP' are (who'd want to name a methodology after a failed operating system, by the way).
Kent Beck = Jim Jones. Beware.
Kent Beck = Jim Jones. Beware.
Never really done pair programming, but I'm struck by how much it's culture-dependent, and how easily it can be undone by initial assumptions. "We'll save money on furniture." "That guy's good, but too expensive."
From my experience on pair programming:
- it occurs naturally if you give two programmers one computer and one problem.
- one programmer becomes tactician/executor, other one becomes strategist/supervisor
- tactician thinks how to make loop to iterate properly, strategists thinks why to make loop and what to do next.
- it helps immensely to have someone who has different ideas than you on your side, if you are willing to submit to this ideas if you don't have other than idealistic arguments against them.
In my experience pair programming works best when used on hard problems. If you're doing the sort of coding where there is no complex problem solving involved and you're basically limited by your typing speed then pair programming is probably just hindrance.
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.
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.
that one guy at work, he either doesn't shower often enough for his type or he never heard of deodorant.
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.
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.
Why hasn't Pair Programming extended itself beyond just programming? What about something like "Pair Accounting"? "Pair Book Writing"? I don't see anyone arguing that the cubicle office is fundamentally flawed, except for in cases where people are anti-social and don't like each other.
Then you haven't been reading much. I've seen tons of objections to cubicles, some anecdotal and some based on scientific evidence such as noise levels and interruptions from people walking by and chatting disrupting flow.
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.
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.
Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them feel productive.
Personally I think pair programming is overrated while code review is still underrated.
Personally I think pair programming is overrated while code review is still underrated.
Pair programming bad. Pair debugging good.
From a quick, unscientific survey of the discussion around pair programming it looks like most of the people who have tried pair programming like it, and most of the people who haven't think it would suck. Is anyone else noticing this pattern?
The article provides 10 reasons why pair programming might not work. Moreover, it says that these reasons are very common:
You write: "most of the people who have tried pair programming like it". Your conclusion is contrary to one of the the article.
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.
Personally the idea of pair programming would suck out the joy of programming for me. I just can't stand the thought of not thinking through what I am doing and talking about it, is way slower than doing it in my head.
I think the point is to think-and-talk instead of think-and-rewrite.
Someone who is able to think and talk at the same speed is either an impractically fast talker or an impractically slow thinker.
sacrifice "speed" for validated thought.
pair programming intends to prevent rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.
pair programming intends to prevent rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.
Spaghetti code is not necessarily the result of fast thinking... shallow is enough... fast or slow.
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.
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.
While you can evaluate elegance and simplicity in your head that doesn't work for edge cases and side effects. That's were talking and writing and sketching are helpful. I don't encounter much code where i can hack with the flow. Mostly the task is either utterly boring or too complex for my little head.
Pair programing is not for everyone. Like any other method. Pair programing is for motivated, enthusiastic and even addicted people. It is a different approach to the problem, which people must have curiousness, motivation and courage to try. Try together.
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.
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.
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!"