Agile Zone is brought to you in partnership with:

Rafael has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

The Power of Pair Programming

02.01.2010
| 9586 views |
  • submit to reddit

Some weeks ago I started practicing pair programming with some co-workers for two reasons:

  1. code some tasks of an user story
  2. get familiar with a new software code base

I haven’t had an opportunity to put this technique in practice a lot before, but I can say it was extremely important and beneficial for the project. Sometimes I was the driver and sometimes I was the observer. The driver is the person who starts coding and the observer is who starts doing the code review. That point is important: code review.

Pair programming encourages the review of the code. Perhaps you won’t have an opportunity to refactor some code as you have when you are pairing with someone. I think code reviews are important because:

  • Reviews increase code quality, because there are 2 people thinking about the same task at the same time.
  • Refactoring areas arise in the design where improvements are needed
  • When you have the strong support of an IDE (as Eclipse), a lot of refactorings (extract method, extract class, introduce parameter, etcetera) are highly automated, it helps keep code clean and maintainable
  • More code is read than written, two people reading the code can understand a lot more about the code base
  • New ideas arise because of different point of views
  • Questions can be solved by the sum of knowledge of the code base

And you? What’s your experience with pair programming?

 From http://rafaelnaufal.com/blog

Published at DZone with permission of its author, Rafael Naufal.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Christopher Brind replied on Mon, 2010/02/01 - 3:22am

I find it has it's uses. If your team is a team of superstars code reviews are less important, so long as the code works. In this situation pair programming is a waste of time as the superstars can only be at most 50% productive. The communication benefits you mention tend to be irrelevant in a team of superstars as this communication just happens (morning stand ups, lunch breaks, out for beers, etc).

That said, I've never been lucky enough to work in that situation. So if your team structure is more traditional, e.g. team lead/senior, couple of devs, maybe a junior, then code review is essential and pair programming can save a lot of time in the long run while mentoring those that need it.

Zqudlyba Navis replied on Mon, 2010/02/01 - 4:02am

Rafael ,

Did you try pair-programming full time 9am-5pm for several weeks straight or

was it ad-hoc on demand a few times over a span of several weeks ?

Milos Silhanek replied on Mon, 2010/02/01 - 7:20am

 We use pair programming in form analyst-programmer. The analyst knows what and programmer how. The problem is previously discussed and coding is fine diamond cutting of the algorithm. If something seems dirty or unclear one of them warns. As a result we get good well documented code and clever algorithm. Pair programming programmer-programmer expects self-discipline and leaving of vainity.

Eyal Golan replied on Mon, 2010/02/01 - 8:47am

Recently I had the opportunity to pair-program. I was mostly the observer, which I found really good.

I paired with a really good programmer who is not very experianced so he has his own bad habits.

Our code was much better than each by itself.

zqudlyba - it was 9-5 for 3 weeks.

It looked as it was waist of 50% time. But I believe it wasn't. Many bugs were found beforehand, and the design is much clearer.

But I did have  an insight. I found out that the most difficult thing is the 'Communication' (In the Pragmatic Programmer there is a whole section for that).

I found out that in pair programming one of the most important things is, to put the ego aside. For both members.

If two egos are involved, then you might get into something like: "why are you doing it this way?" "because this is the best way". "no it isn't". and so on and so forth..

In pair programming you must be open minded and to listen.

 

Rafael Naufal replied on Mon, 2010/02/01 - 2:03pm in response to: Zqudlyba Navis

Some days it was full-time but most of the time it was on demand few times during the week. I think pair-programming improves the quality of code a lot, because there are two people suggesting better design while coding. Also it enhances better communication accross the team, a common sense of terms is achieved and the understanding of the code base is increase.

 BTW, I don't think pair programming has to be applied all the time, sometimes is important to develop your own solutions and discuss it with the other team members.

Sathish Kumar replied on Wed, 2010/02/10 - 12:53am in response to: Rafael Naufal

Based on the nature of task severity(simple/complex/normal),we need to identify whether pair programming is needed/not.

As there is no doubt,thru pairing there is improvement in code quality,hence later risks can be handled easily.

pairs should understand importance of listening and providing good solutions together.

 

 

Milos Silhanek replied on Sun, 2010/02/21 - 5:43pm in response to: Rafael Naufal

Some methodologies recomend pair programming as a basic mode of the work. 
Is it available if the both are very busy?

I like to get some complex task. I think out it, I explore several variants and I like discuss the problem with somebody who has bird-eye view. I grew out on codding and I have learned viewing from above.  So we by difficult complex problem use pair analyst-programmer and it is very effective. Sometimes we find new detail problem to discuss with our customer. it is interesting.

Sindy Loreal replied on Sat, 2012/02/25 - 7:30am

I haven’t had an opportunity to put this technique in practice a lot before, but I can say it was extremely important and benefit for the project. Sometimes I was the driver and sometimes I was the observer. The driver is the person who starts coding and the observer is who starts doing the code review. That point is important: code review.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.