Many people do not believe in Pair Programming (pairing). Most of those people don't agree with the benefits of pairing. However, my friend does believe that pairing is beneficial, he just does not believe in pairing all the time.
This is where semantics become very important. He was defining all the time as every minute that you are at work. I define all the time (in terms of pairing) as when I'm writing code that I'm going to commit.
There's plenty of time in the day that I spend on my own. Here's a few examples, but it's not representative of everything I do solo.
- Read about a library that might help us later on.
- Spike a new way to solve a complex problem.
- Debug a tricky issue.
Patrick Kua talks about working in two different modes, Experimental and Focused, in the context of Test Driven Development. I agree with Patrick and I believe the discussion also directly applies to Pair Programming. When you know what you want to get done, pairing ensures that you do it well. But, when you don't know what you need to do, it's generally a pain to try to talk through the problem with your pair. Talking through a problem can be helpful, but I often like to get a decent understanding before trying to explain it to someone else. I also like to be able to stop going in one direction and immediately switch to another if I spot something interesting.
Pair programming is a good thing, but like all good things, it's best when done in moderation. There are times when you do not need to pair, and Wikipedia has a decent list of reasons that people are opposed to pair programming. But, those things should not discourage you from giving Pair Programming a fair shot.
Given the right set up and approach, I believe pairing is the most efficient way to deliver quality software.
I see inconsistency. In you post "when not to pair" you say that things where it is clear what to do should not be paired on. The experimental mode seems to be the opposite, hence should be done by pairs.
ReplyDeleteAt my company the odd person is spiking whole day. Do you do it at Thoughtworks? (do you have one-day pairs anyway?)
Hello Kamil,
ReplyDeleteI can understand why it looks like inconsistency. I would phrase it like this:
If I have no idea what I'm doing, I like to spend some time spiking on my own. I do not check this code in.
If I know what I'm doing (more or less), I work with a pair and commit that code.
If I know what I'm doing and there is only one correct answer, I will work alone. However, this situation is so rare that it almost never happens.
The pairing situation at ThoughtWorks varies by project. It often depends on client preferences and team size and make up. My blog entries are very much based on my experiences and not necessarily representative of all of our projects.
Generally, on the projects I'm a part of, we switch on a daily basis. If we are odd, we try to have the odd person work on spikes or very easy tasks.
Thanks for the comment, Cheers, Jay
"Debug a tricky issue."
ReplyDeleteIMHO, that's the best time to pair-program. You have two brains working on the issue and you're forced to articulate your thought process.
Why do you feel otherwise?
Sometimes I need to play around without explaining what I'm thinking.
ReplyDeleteHowever, I recognize that 2 heads is better than 1 when figuring something out so it really depends on the situation.
I'm almost always pairing so I generally start debugging with my pair, but if I feel like we are moving too slow with our current direction, I'll break off and try a few ideas on my own.
Again, it really depends on the situation.
I'll tell you this much : I have gotten mixed results out of it. Mixed as in, if someone is good programmer generally he fares well with me (If he is too good, we fight most of the time on how things can be better ... it depends, i dont like guys who vehemently support some type system or some paradigm of programming that comes in way of practical things, if you know what i mean, but if he is a bit of a downer or a newbie i find it hard at times; especially when there are time pressures and dead lines =(
ReplyDeleteAnd then there is coding conventions, standards, personal ego (which i am guilty of mostly, in the sense that i like to see the code the way i want it to be (i guess all programmers are guilty of that)).
Regards
Vyas, Anirudh
Anirudh Vyas