This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: Pair Programming Redux
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
You're a prolific blogger. Does that mean that you don't pair? Or that pairing doesn't really stop you goofing off at work?
Well, I'm not really a prolific blogger, except maybe in relative terms. The only real response I have is that 1) I mostly blog during breaks and non-work hours and 2) I blog a lot less when I'm on a project where I'm pairing most of the time.
I went back and read what I wrote and I didn't say anything about pairing 100% of the time or forcing it on people. Just my personal opinion that pair-programming is a very effective way of maximizing developer productivity.
We, developers, are not always in the mood for pair programming.
Some days we need our quiet space to think. We need some "freedom."
Sometimes we need to deal with personal stuff that, unfortunately, needs to be taken care of during regular office hours
Two developers can pair (and be productive) if there is compatibility in their personalities and skills. We need to feel comfortable with each other.
...pair programming should not be imposed. We should treat it as any other tool and use it when we think is necessary. In order to do so, we need to know what a tool is good for. Honestly, I'm skeptical about the pair-programming-increases-productivity doctrine.
Well, based on my personal experience I'm not skeptical about it. If you've worked on a team that pair-programmed most of the time then you probably know what I'm talking about with regards to productivity gains -- you just can't slack off as much as when you are allowed to work alone most of the time. Am I saying that pair-programming should be imposed? No. Somehow though, some people read that into my words. Tom Mayerst refers to my description of developers that pair-program ThoughtPolice. Geez Tom, that's unnecessarily dramatic. I do get it:
For the record a team will work hard if they get enough internal satisfaction from doing so. External factors such as threats, rewards or the Thought Police have been demonstrated over and over to fail. How you foster that internal satisfaction is where the ?art? of management comes in.
I also must have failed to convey the pride and satisfaction that comes from successfully putting pair-programming into practice on a team. It has nothing to do with coercion, and little to nothing to do with the "art" of management. Techniques that make me and my team more focused and productive are a "good thing" in and of themselves and they feel great -- they sure are more motivating to me personally that knowledge sharing and a lot of the other good stuff you get with pairing.
Gordon responded:
Pairing is one little bit of Being Agile. Not pairing doesn't make you not agile. It just means you prefer not to pair.
Amen! You won't find me trying to ram pair-programming down anyone's throat. In order for it to work, it has to happen with happily willing participants who really see the value of it. Among those values? Higher productivity, which is the main point I was trying to make. Really!
Another ex-ThoughtWorker, Ravi sniped:
If the key benefit of pairing is that it keeps otherwise lazy developers' nose to their keyboards, the company needs to look more carefully at the type of people it hires than at its development methodology.
Dammit, that really upsets me. It's not about laziness -- it's about the predominance of ATTENTION DEFICIT DISORDER, whether diagnosed or not, acknowledged or not, ADD is affecting almost all of us, probably as a result of the tons of distractions that we are subjected to on a constant basis. Working on something with a partner works miracles for postponing non-essential distractions such as IMs and checking emails and blogs. Don't suffer from ADD at all? Well, good for you. Your type of people will be in the minority soon if you aren't already.
Thankfully at least some of you got what I was talking about, for instance...
Dominic says: Heh, you've hit the nail on the head. I'm just not able to keep up the same rate of work when I'm on my own. Pair programming might not be wonderful for everybody, but for me it helps to maintain a level of concentration that I can't hope to achieve on my own...
Finally, since I addressed Steve Yegge personally with my comments and (even though I didn't intend it) they might have been taken in a derogatory fashion (sorry!), I'll end this post replying to a couple of his comments:
I love pair programming. I do it often. What I don't like is mandatory full-time pair programming. That's what XP required, at least initially, and the requirement did far more harm than good to their overall message.
I think there are people and situations where full-time pair-programming can and will succeed brilliantly, but I think we agree that making it mandatory in all situations does more harm than good.
If you read further down my post, you'll see that I talk about pair programming again in the context of Google's fishbowls. When you seat teams together in open seating (not cubes), then engineers will go sit at each others' screens and pair-program naturally, exactly at those times when it's most helpful.
So in other words, spontaneous pair-programming happens naturally and successfully at your group in Google. That's great! You've made it clear though that Google is a pretty special place, and Google hiring standards are pretty frickin high -- higher than everyone else I can think of. So it doesn't change my mind that human nature being what it is, it's worthwhile to pair-program as much as possible. I maintain that most developers are significantly more productive when they pair-program. Full-time or part-time? Do whatever works best for you. YMMV
Previous Topic
