Slashdot Mirror
The Programmers Go Coding Two-by-Two — Hurrah?
theodp writes "The Wall Street Journal reports that pair programming is all the rage at tech darlings Facebook and Square. Its advocates speak in glowing terms of the power of pair programming, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web. 'The communication becomes so deep that you don't even use words anymore,' says Facebook programmer Kent Beck. 'You just grunt and point.' Such reverent tones prompted Atlassian to poke a little fun at the practice with Spooning, an instructional video in which a burly engineer sits on a colleague's lap, wraps his arms around his partner's waist and types along with him hand over hand."
Like many workplace practices, it's something worth trying, but not something to be trumpeted as "the way" to do things. Some people get on with pairing, some don't. And it's OK either way. Likewise, there are writers who work in pairs, but many who do great work alone. There are architects who work in groups and alone. So it goes for software developers.
Where it goes sour, however, is when people who find pair programming valuable start tarring anyone who doesn't do it as being error-prone slackers.
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much.
I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
If the Facebook team is using pair programming for their mobile apps (on all platforms!), maybe they should try something more traditional because it's not working! They have so many bugs and glitches in the IOS, Android (tablet), and Blackberry apps that they definitely need to try a new approach! Maybe if they TESTED them before releasing, they'd have better results?
This space for rent, inquire within.
All the time i did pair programming it was me doing all the work and the other guy just pointing silly stuff like "missing ;"
I can't think of ANY one that I want to spend that much time around.
My wife can't code, but I would not want to spend that much time with her either.
Now, maybe my girlfriend. But I don't htink we would get much coding done. Besides, she can't code and I don't care.
>and are less likely to waste time surfing the Web
You obviously haven't heard of the phenomenon of "pair surfing".
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
I know it's just a summary and all, but it makes me feel vaguely sad that out of all of the things you can say about him, Kent Beck is tagged as a "Facebook programmer."
so it's eXXXXXTreeme programming again?
couldn't they at least fucking re-use the term.
oh and it's not so bad for some small crunch period.. but for longer periods it really shits on my slashdot browsing habit.
am I now officially old? since they tried selling us this XP shit back before I dropped out of uni.
world was created 5 seconds before this post as it is.
More Programming, Motherfucker.
If my boss sees this, and pairs me up with L.....before day one is out there will be two fewer programmers. One dead, and me in jail.
We used to call that eXtreme Programming: that was the rage a while ago, then went out of fashion in favour of other agile development methods. But that happened a lifetime ago (the early 2000s :p ), and computer fashion have changed more times than I can really keep track.
I guess that the people who were actually programming 10 years ago are now managers, gurus or architects and want to bring back their happy childhood memories (id est, programming with their buddy) back to reality, imposing it on the newer generations.
It's not for everybody - nothing is - but it's definitely worth trying with an honest effort.
Dare to Hope. Prepare to be Disappointed.
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much. I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
Or it has something to do with experience. The elder programmers have seen many programming fads come and go, many claims for the "one true way" to greater efficiency and reducing bugs. Like most fad/pop things, pair programming probably worked in a specific environment, with specific people doing a specific type of task ... but is probably not a universal solution. It is merely hyped as such by the "training" industry, book sellers, etc.
Elders may realize when working in pairs will help and when it will not. I've seen plenty of instances when elders call in a peer for an hour or two for a particular bit of code and then part when returning to the more mundane parts of the code. Or ask a peer to review a bit of code they just wrote.
We have one big cube with one computer and we put all of the programmers in there. We call it the stable and the programmers are now just referred to as the herd.
Just be disciplined with design and code reviews and be done with it.
This doesn't sound like a plan to improve performance, it sounds like a plan to cut costs on hardware, now you can have one computer for every two devs.
I'm god, but it's a bit of a drag really...
I think we can all see where this is going.
Programmer centipede.
You know I'm right.
I've had experience with pair programming. In my mind here are the pro's:
1. It keeps you engaged and prevents your mind from wandering.
2. It is a great way to teach junior level programmers, many of whom suffer from a lack of training and are thrown to the wolves in the beginning of their careers. I would have LOVED pair programming (in small doses) when I was starting out. It's a great way to learn things about a complex system that are not obvious.
3. Different people tend to approach problems differently, and this difference in perspective can make it easier to catch bugs that are not obvious to a single programmer.
The Cons:
1. When abused, it can reduce productivity by distracting coders and not allowing them the space they need to think.
2. It can create a hostile environment where the employee feels that they have no privacy, room to think, and where they are constantly being watched. This is part of why I think management loves it so much, they are outsourcing micro-management to their underlings.
3. It can reduce motivation of individual developers since the buck no longer stops with them, but instead is the group's (or pair's) responsibility. While diffusing some responsibility across the team is not a horrible idea, people tend not to be as motivated. I observed motivation take a big nose dive when the shop moved to XP, since people were no longer as accountable for finishing anything, they just had to come up with a BS explanation for what they did the past day during the scrum, and really, it's a lot easier to BS one day at a time than it is to explain just what the hell you've been doing the past two months.
4. Many poorly designed XP programming environments are inherently disrespectful, and are merely an attempt to turn a programming shop into a factory floor with no privacy. As a skilled programmer, I won't go along with this, and I actually refused to move into this kind of space at my last job, and instead left, along with the majority of seasoned developers.
Overall, I can get some of the benefits of pair programming by walking down the hall, grabbing another team member and saying, "Hey, could you take a look at this?", when I'm having trouble finding a bug. It shouldn't require them to sit there all day.
Let's face it...this is yet another iteration of the dance we've seen before. Extreme Programming, Agile Programming, and so on. Companies keep hoping that there's a methodology that can be applied to the process of coding and development that will homogenize their workforce, allowing them to look at coders more like cookie-cutter individuals. There are multiple drivers behind this: the difficulty of assessing a programmer's talent during the recruiting process, the desire to use cheaper resources, especially in outsourced business models, and the challenges that result from coders who turn out not to be a good fit with their role. But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.
For your security, this post has been encrypted with ROT-13, twice.
Fixed that for you
1999 called, they want their useless waste of resources techniques back. Nice try Kent trying to jam Extreme Programming on us again.
I'm a good cook. I'm a fantastic eater. - Steven Brust
But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.
What some want is for it to be more like "paint by numbers". Sometimes it's OK, but as you say, most of the time it's a poor fit.
Unix is user friendly, it's just selective about who its friends are.
Facebook programmer Kent Beck.
That seems a little like saying, "Google employee Vint Cerf."
And, as an aside: Damn, Kent. Facebook? I thought you were cool.
Stop-Prism.org: Opt Out of Surveillance
the driver writes code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in.
Driver sounds cool, that's what fighter pilots call themselves too. But observer sounds lame... we should call it wingman. Then we have the driver who writes codes, and the wingman who watches for errors. Plus we get to say cool stuff like,
"You can be my wingman any time!"
I see paired programming as just another gimmick to get around the fact that there is no substitute for having experienced programmers and effective code reviews. As a consultant, I've worked on many agile projects, including some involving strict XP paired programming, and didn't see any better quality with that than with anything else. It's all about who you have working on the project, having decent management and a true agile philosophy ... not "agile theater."
Yeah, if you want the seasoned vet to commit seppuku...
Nonsense. One of the tasks implicit for any seasoned vet (especially one that is vested as a senior or principal) is to guide juniors or new members of the team up to speed. Obviously, you don't want your vets to be paired with juniors all the time, as this is not economical (and at some point the junior needs to hit the ground running by himself/herself).
However, in any company (and for any job for that matter) it is a person's task to help others come up to speed if that person has the necessary know-how. It might not be the case for those who just want to fold jeans at the gap, but it is certainly true above a certain professional/salary level.