| |
|
Pair Programming: Two heads are better than one |
|
|
|
Written by Parag Shah
|
|
May 18, 2005 at 01:54 PM |
|
Page 1 of 2 Pair programming is the practice of two programmers working together on the same terminal and on the same task. I use the word task because the pair could be working on a design issue, coding, or even documentation.
One person is the driver and the other is the observer. The driver has control of the pen/keyboard, etc and contributes by coding or drawing design diagrams. The observer wears the hat of a strategist. He or she observes what the driver is doing to analyze its correctness and also to understand how well it fits into the big picture of the software being developed. Developers switch roles as well as pairs during the duration of a project.
{mosgoogle}
Pair programming initially seems like a very unorthodox way of working. Developers are used to the notion of code ownership and solo programming. Some initial reservations people often feel are:
- Code ownership improves quality of code because developers would not want their code to be of bad quality. How can a methodology which eliminates code ownership produce good quality code?
- Why have 2 people work on a task, when one person can do it in the same time?
- Developers will not want to work together because of ego clashes.
The above reservations may initially seem very intuitive and correct, but in reality studies have shown them to be incorrect. Let us take each reservation separately and analyze it.
Code ownership improves quality of code It is true that when developers own the code they write, they try to make it as good as possible, because after all, it is their reputation at stake. However individual code ownership diminishes the chances of peer review. Peer review has been found to be very helpful in increasing code quality.
During pair programming the code and design is reviewed immediately. Thus if a developer makes a mistake due to an oversight, it is very likely that his pair will point it out. Also when dealing with a particularly difficult coding or design problem, it has been found that 2 developers will explore a larger solution space and will find a better solution.
Having 2 developers working on a task would be wasting human resources If we apply simple mathematics here, we can conclude that if 1 person takes 100 hours to code a particular task then 2 people working together on the same terminal and the same task would also take 100 hours, which is actually 200 person hours. Why would we to spend double the time and reduce productivity? Studies have shown that when people program in pairs they actually code faster taking only 15% more time [2]. It has also been shown that the resulting code has 15% fewer bugs.
We all know that if a defect is caught early in the development cycle, the cost of rectifying it is a lot lesser than if they were caught later. In pair programming, since all code is reviewed immediately when it is written, many defects are eliminated almost right away. This results in significant savings in time that would be spent in removing these defects, had they been caught later in the development cycle.
The 15% extra time that the pairs take is more than compensated by the time saved in QA related tasks. The saving can be as much as 60 times the extra time spent due to pairing [3]. The resultant code is also of a significantly higher quality thus increasing the robustness and flexibility of the software.
<< Start < Previous 1 2 Next > End >>
|
|
|
|
Home | 
