The Power of Pair Programming
Some weeks ago I started practicing pair programming with some co-workers for two reasons:
- code some tasks of an user story
- 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?
(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
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
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.