SAN MATEO (07/24/2000) - Some things just seem like they were meant to be done alone: playing solitaire, driving a car, reading a book. The same goes for writing code. When you think about software development, you probably imagine a single person sitting in front of a computer screen, intensely cranking out lines of code. (OK, you might also picture empty pizza boxes, soda cans, and perhaps a bag of potato chips.) But is the "solo pilot" method the best way to organize a development team?
Proponents of a relatively new coding philosophy called pair programming -- part of the extreme programming, or XP, approach -- claim that, by teaming developers into small, two-person units, you can not only improve the quality of your applications but also increase developer satisfaction. The XP crowd asserts that you'll save money, too: Because software quality will be better the first time out of the chute, you'll allegedly spend less time in redevelopment, and because developers will be happier, you won't incur the expenses of losing key employees. (No one has yet made any predictions concerning pizza, soda, or potato chip intake.)Also known as collaborative programming, the pair programming method involves seating two developers side by side on the same computer, where they work on the same piece of software together. To many companies, this notion -- splitting coding duties between two programmers and forcing them to share a machine, no less -- may seem inefficient, awkward, and downright unprofitable.
So why has pair programming become such a hot topic? In this Test Center Analysis, we'll provide some answers.
Collective code ownership
First let's back up a bit. How does a pair programming development project begin? Under the XP model, much of the project design work is guided by CRC (class, responsibility, and collaboration) cards -- slips of paper that represent objects in a given project. Each card lists the class, responsibilities, and collaborating classes of an object.
Before a project begins, the project team holds meetings in which team members simulate the interrelation of all known objects, using the CRC cards as visual aids. Programmers are encouraged to discuss problematic areas and reposition or add cards to represent changes to the plan. By depicting objects as individual entities, complex constructs can be simplified into a clear design.
The result of a CRC session is a list of small tasks that must be performed. At this point, developers are paired up, and each pair defines a unit test for its assigned task. Note that unit tests are created before any coding is done.
According to XP advocates, this approach makes application development easier and faster: your tests are more accurately written to scrutinize mission-critical functionality, you get immediate feedback on what needs to be done, and you don't waste time creating oversized tests to check over the entire project.
Next, each development pair begins coding to meet the specifications of the task at hand. A seasoned programmer is always paired with a less-experienced developer: The latter "drives" -- takes the keyboard and types -- while the former looks over the novice's shoulder. Hence, the "driver" is responsible for code-level development issues, such as syntax and proper construction, while the "planner" is charged with plotting the overall logic of the project and catching coding errors in the driver's work.
But adopting the pair-programming model does not mean that two developers must be joined at the hip for the entire duration of a project. Things can be much more flexible than that: The programmers may only be paired to work on a single module or a particular function, for example, and would then be free to move to different teams later. Work roles aren't rigidly defined, either -- the keyboard may change hands frequently during the coding process.
Once code is developed that addresses the assigned task, the unit test that was previously defined is executed. If the code does not pass the test, either the unit test or the code may be changed. If, on the other hand, the code does pass, it is integrated into a code repository, where it can be accessed by every other member of the development team. Updated code should be placed in the code repository every few hours (and at least every 24 hours). In this way, all of your developers can stay current, and it's less likely that errors related to versioning problems will be introduced into the project.
If during the course of coding the partners find that they need help with a particular coding issue, the members can ask to form a new pair to look at the problem. Usually one of the original two will join a different pair while one stays behind to address the issue with a different developer.
During the coding process, XPers also practice a technique called refactoring.
This involves constantly working to simplify the code, thereby making it as concise as possible. By keeping code clean and defining things only once, programmers will go a long way toward reducing defects later. Refactoring brings errors into the open more readily, and those errors can be addressed right away.
The final step is to run all the unit tests as well as the functional tests.
This process may need to be repeated several times before all the objects are working and interacting properly. Several CRC sessions may be needed; objects that failed functional testing should be reassigned to a pair of programmers for another iteration.
And what about the developers themselves? The benefits of pair programming to less-experienced programmers are obvious: They get to work with knowledgeable mentors, giving them an opportunity to quickly expand their knowledge. But pair programming is not about forcing experienced developers to train neophytes. Old pros can benefit, too: By leaving the mundanities of code-level details to someone else, seasoned developers can shift their focus to more abstract business issues that must be addressed in the code. Ideally, the two programmers should work and learn in tandem.
Academically speaking
Of course, a development method is only as good as the applications it helps create, and the principles embodied in pair programming signal such a radical shift in traditional development practices that, not surprisingly, its benefits have been routinely questioned. To that end, the method was studied in 1998 at Temple University, and again in 1999 at the University of Utah. In both cases, some students worked individually while others worked in pairs to solve problems.
The results: The paired groups consistently wrote more concise code, produced fewer defects, and reported that they enjoyed the process much more than they would have had they gone it alone. On the other hand, the paired groups also took slightly longer to complete their initial tasks than the solo programmers.
But subsequent iterations of the process yielded more rapid results. Thus, although it may take developers longer to get through the process the first time through -- suggesting that pair programming may not be the best solution for extremely time-sensitive projects -- it also seems that developers adapt to the process quickly.
That's not to suggest that pair programming is always a good idea. Some programmers find coding to be a very personal activity that becomes awkward when shared. Also, many business leaders and managers shy away from the idea of doubling up much-needed development resources. Personality conflicts can make working in pairs impossible, too -- some people simply do not work well with others. Other mitigating factors include different physical locations for developers on the same project and conflicting work schedules. Finally, the approach requires having enough experienced programmers on staff to act as team leaders.
It remains to be seen whether pair programming (and extreme programming, for that matter) will catch on. At companies that have already adopted the method, such as DaimlerChrysler and Ford Motor Corp., it's still too early to assess the results. But if you're nervous about the age-old concerns of application development -- communication between programmers, unnecessary complexity, monitoring and control enforcement, and of course, software quality -- pair programming may be worth a try.
Maggie Biggs (maggie_biggs@infoworld.com) is the director of the InfoWorld Test Center. She has more than 15 years of business and IT experience in the financial sector and has coded numerous projects.
Additional resources
XP general information
www.xprogramming.com
www.extremeprogramming.org
Pair programming general information:
www.xprogramming.com/Practices/PracPairs.html
c2.com/cgi/wiki?ProgrammingInPairs
Pair programming costs and benefits:
members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostben
e.htm
Virtual pair programming: c2.com/cgi/wiki?VirtualPairProgrammingNewsgroup: comp.software.extreme-programmingMailing list: Send mail to extremeprogramming-subscribe@egroups.comMagazines: www.xprogramming.com/xp_magazine.htmTHE BOTTOM LINEPair programmingBusiness Case: According to its proponents, pair programming can deliver significant gains in software quality, staff knowledge, and developer satisfaction. But not everyone may be comfortable working in two-person crews.
Technology Case: By forcing pairs to release functional modules to the rest of the development team at least once every 24 hours, the pair programming method seeks to increase collaboration and shared knowledge.
Pros:
+ Fosters continuous learning
+ Enhances teamwork and communication
+ Enables rapid problem solving
Cons:
- Not yet widely proven to be effective
- May introduce communication or personality conflicts- May lengthen development cycles.