| |
|
Pair Programming: Two heads are better than one |
|
|
|
Written by Parag Shah
|
|
May 18, 2005 at 01:54 PM |
|
Page 2 of 2
Developers will not work together because of ego clashes or differing working styles Most people have their own unique style of coding and approaching a problem. It is felt that pair programming would work well only if both developers had a similar style of working. Studies have found this myth also to be untrue.
Even though people do have their own style of coding and problem solving, most of the time they are not averse to working in pairs. In fact it is a well known adage that ?Two heads are better than one.? When two people work together on solving the same problem they explore a larger solution space enriched by their unique experiences. Most likely they will solve the problem with a more creative and efficient solution.
The fact that developers in a pair bring their experience in the way they work very often results in spontaneous learning. Working in pairs can also be a socially pleasurable activity which helps the team to reduce work related stress.
Other BenefitsFar from being unproductive and difficult to implement, pair programming has yielded several benefits. Some of them include:
- Economic benefits
- Work satisfaction
- Better design quality
- Increased learning
- Team building and communication
- Decreased impact of employee turnover
Here are some things that developers have to say about pair programming:
?The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you may not like it because you are not used to it. However the more you eat it, the more you like it.?
?As we proceeded with our work, I started to notice that one team consistently produced designs of distinctly better quality than the others. I asked them about this.
They said that they had taken to working together, on both the design and the programming. They found that their designs and programs were better this way. I agreed with them and made it standard for all teams to work in pairs. The design quality is now better?
[From the interview files of A. Cockburn]
?We came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design?
?There were times we felt that we would have given up except that we ?tag teamed.? I?d be on the ropes and I?d describe the problem in such a way that he had a valuable insight. Then he?d fight on as long as he could and stop?then ?id have an insight?and so on. I suppose others would call it brainstorming, but it feels different to me.?
AuthorParag Shah graduated from the University of North Carolina at Charlotte with a Masters degree in Computer Science. While he was studying at UNCC, he had the opportunity to work with IBM on a research project on ?software collaboration techniques? for the CIIMPLEX consortium.
Following his graduation Parag worked for an eCRM startup company before returning to India. Since then he has been working as an independent consultant under the commercial name of Adaptive Software Solutions. Parag has offered J2EE consulting and training services to several organizations in India, and is also adjunct faculty at SCIT - Pune. Other activities include publishing a monthly newsletter on Software Design and Processes. Parag brings over 8 years of industry experience in various aspects of software development.
References- L. L. Constantine, Constantine on Peopleware, Yourdon Press, Englewood Cliffs, N.J. 1995.
- Williams, L., et al., Strengthening the case for Pair Programming, in IEEE Software, submitted to IEEE Software. Online at
- Alistair Cockburn, and Laurie Williams, The costs and benefits of pair programming.
|
Comment by Noname on 2005-05-19 20:43:33
All your points about how pair programming can be effective are only true if you happen to have 2 developers who work well in that particular environment. Pair programming is not a practice that you can generalize across a development team without 100% complete buy-in from all your developers. I recently blogged on some XP practices in which I commented further on pair programming. See Timothy Fisher's Java Blog.[URL=http://timothyfisher.javadevelopersjournal.com]Timothy Fisher's Java Blog[/URL] |
Comment by Noname on 2005-05-25 13:42:53
I agree, pair programming can work only if the entire team buys into the concept. Many developers have a personality type which makes pair programming almost impossible. I do not think there is anything wrong with this. Certain people prefer working independently, and that is fine as long as they have the big picture of what the team is trying to achieve. Having said this, pair programming works wonderfully when we are trying to solve a particularly difficult problem. I am sure there is place for personal heroics here, but I have experienced that very often when two developers try to solve a problem collaboratively they come up with a better solution, than what they would have done independently. This does pre-suppose that both developers are inclined to collaboration. If they are not, then they might end up in a stalemate and argue endlessly about which is the better solution, without arriving at any conclusion.
Pair programming also works well when an experienced developer pairs with an inexperienced one. It is a very good learning experience and can help the new developer raise the bar of his work quickly.
Overall I do agree with you that the effectiveness of pair programming will depend a lot on the culture of the team and individual personality types. But something can still be gained by practicing it partially in situations and with people who can benefit from it.
|
|
|
|
|
Home | 
