Pair programming is the practice of two programmers working together on the same terminal and on the same development-task. One person is the driver and the other is the observer. The driver has control of the keyboard 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.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 two 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 two developers will explore a larger solution space and will find a better solution.
Having two 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 spend double the time and reduce productivity?
1. 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 it 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.
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. 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, specially if both of them belog to different gender anf ofcourse it helps the team to reduce work related stress.
So enjoy pair programming...
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 two developers will explore a larger solution space and will find a better solution.
Having two 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 spend double the time and reduce productivity?
1. 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 it 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.
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. 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, specially if both of them belog to different gender anf ofcourse it helps the team to reduce work related stress.
So enjoy pair programming...
No comments:
Post a Comment