I never liked the rigid position taken by the XPers on "Pair Programming"- one programmer typing away while the other sitting next to him watching over his shoulder. People, particular PMs and clients, are weary of this practice thinking that it is a wastage of time, and hence money. I am with the PMs and clients on this. I don't like this practice because this not how we the programmers naturally work. And hence it cannot be as productive as it is claimed to be. Yes, I know there are studies throwing numbers like "15% improvement in quality while only 15% slower than two solo programmers." Why would I want to be 15% slower (hence pay 15% more) if I can maintain the same quality (difficult to prove either way though)?
I understand how this "pair programming" came about. What we the programmers naturally do is that we talk and interact with our fellow programmers sitting next to us or in front of us as we work on our codes on a daily basis. Sometimes, we look over our fellow programmer's shoulder to help or to be helped. This is natural. However, formalizing this is over the top.
What we have been doing at Code71 is what we call "Pairing on a Story." That is, at least two developers pair on a single story and take on different tasks. They coordinate to deliver the story. We usually like to pair novice-expert. This way you avail all the advantages of pair programming without the disadvantages as well as get the support from the PM or client.
Are your pairing or pair programming? Like to share your experience?
stoppair programming meets the biggest resistance from developers and project managers alike.
ReplyDeleteThe project I'm currently on is doing pair programming, and to be honest it doesn't always work all the time. But I see a huge benefit in leveraging "partial pair programming"
-enforce at least 2 hours of real pair programming a day.
-when a developer is stuck for any reason, callout for a pair, other developers should be made aware that helping the pair is more important than doing one's own work.
Why?I I have found pair programming to be the best way to enforce common coding norms, alignment to common design, share knowledge, ensure there is no one single developer you can't afford to loose etc.
Your approach while reasonable, is what I call regular team coordination, and while there's nothing wrong with it, it's not pair programming, not even close...
My advice to everyone out there is to actually get on a project and experiment with it, you may or may not elect to go with it, but it's worth a real evaluation.
Jeff Anderson
Jeff,
ReplyDeleteHelping a fellow developer out by sitting next to him coding with him is what I call natural pair programming. We do not have to enforce it. We developers were doing that for ages now.
What I am suggesting is not "pair programming." And I agree with you. I call it "pairing" or collaborative coding on the same story. That is two or more developers are breaking a story into tasks and each taking on tasks and collaboratively implementing the story.
So, I am not espousing "pair programming XP style".
Syed
hi,
ReplyDeletethanks for nice writeup.
we used to team up with small group of programmers, designers and qa persons (5 to 6 persons). so we can't always take advantage from pair programming. but most often we pairing two persons to remove impediment.
like you said, assisting fellow programmers is one of our basic instincts. but i belief you can't easily achieve pair programming advantages by practicing this over night or month. it should take few more times to understand the real importance to those who will write code holding a pair of extra eyes on his own shoulder. even i don't think mix expertise could always come up with better pair.
since less experienced and experienced might have different way of solving the problem also different way to write them in code. rather if you have similar expert guys who broadcast and tune their antenna in the same frequency. that might help them to boost their productivity.
i belief, if you could setup up this kinda pair 1 or 2 (similar expert) that might bring magic on your project.
obviously for training purpose you could set up pair, but not obviously for mission critical project or not even for those project where sprint performance is very important. no dela dala kaz.
best wishes,