Thursday, June 25, 2009

Pair Programming

This blog entry summarizes the key points of the paper by Laurie A. Williams and Robert R. Kessler which is about Pair Programming. "Pair programming is a style of programming in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code or test." It is one of the core practices of eXtreme Progamming (XP).

We as programmers are conditioned to work alone, as we are too much under the impression that thinking independently will allow us to formulate our deeply-concentrated thoughts better. Studies, however, show that pair programming allows us to become more efficient programmers.

The key importance lies in the below mentioned attributes:
1) Continuous code review by person watching over the shoulders
2) Exchange of ideas which could disclose possible flaws, and bring about improvements
3) Efficient, and a greater confidence in the solution
4) High level of code quality which is nearly bug free
5) Enjoyable experience

The paper then talks about the important principles of pair programming. Here are some of those:

SHARE EVERYTHING and PLAY FAIR
Two programmers are assigned to produce one artifact - design, algorithm, or program, etc. Both partners are working actively, even though one is putting the ideas together whether in a code, or in a design on the paper; the other partner on the other hand is continuously reviewing the work. Both are equally creditable or liable.

BEING LESS OF A SLACKER
I realized that I check my Facebook account, and dozens of email accounts quite frequently even though I know I am expecting nothing but tonnes of spams. And when I am saying frequently, I mean it... I mean at least once in every 15-20 minutes. While, working over the past two projects, I realized that I barely check my accounts while I am working with my partner, unless we are taking a break. In essence, I am much more focused and dedicated, and being less of a slacker :).

EXCHANGE OF IDEAS
Honestly, I have learned a lot over the past 3 weeks. The way my partner thinks, motivates me to think differently, allows me to think out of my own little box of ideology. Continuous discussion, and constructive arguments are the best training, I believe.

DON'T TAKE THINGS TOO SERIOUSLY
"Ego-less programming" as the mentioned in the paper, is the key to fully take the advantage of the pair programming. The arguments should be taken as a resource to further hone an individual's programming skills.

WASH YOUR HANDS OFF SKEPTICISM BEFORE YOU START
There should be no scope of skepticism with pair programming; if something looks confusing or non-understandable clarify the doubts. But, trust your partner. Engage in constructive arguments if need be so. One idea is that the outcome of a union of team members is more than the disjoint sets of members, contrary to traditional set theory. As experiences have shown, a pair produces more than twice as many solutions than the two working independently.

FLUSH/REVIEW WORK DONE INDEPENDENTLY
We have other commitments of time and we need to be working on some tasks independently, or just for some deep-concentration thinking. However, it is the best practice to review the work done independently together with your partner; it could possibly disclose a plethora of subtleties.

And finally,
ALL WORK and NO PLAY MAKES everyone dull... so take breaks occasionally.

For cost/benefit analysis of the Pair Programming methodology, I came across a paper by Alistair Cockburn, and Laurie Williams.

No comments:

Post a Comment