Motivation: Completing Jobs on Time with High Quality


The technique of pair programming has been recently popularized by Extreme Programming though reports of pair programming pre-date the emergence of the technique. In his 1995 book, Constantine on Peopleware, Larry Constantine reported observing Dynamic Duos at Whitesmiths, Ltd., producing code faster and more bug-free than ever before [Constantine1995]. That same year, Jim Coplien published the "Developing in Pairs" Organizational Pattern [Coplien1995].

In 1996, there was a report from Hill Air Force Base [Jensen1996].

The two-person team approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code and documentation as if the team was a single individual… . Final project results were outstanding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization's norm. Was the project a fluke? No. Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walkthroughs, mentoring and motivation.

In 1998, Temple University Professor Nosek reported on his study of 15 full-time, experienced programmers working for 45 minutes on a challenging problem important to their organization, in their own environment and with their own equipment. Five worked individually, ten worked collaboratively in five pairs. Conditions and materials used were the same for both the experimental (team) and control (individual) groups. This study provided statistically significant results, using a two-sided t-test. "To the surprise of the managers and participants, all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions." Combining their time, the pairs spent 60% more minutes on the task. However, because they worked in tandem, they were able to complete the task more quickly and effectively by producing better algorithms and code in less time. Most of the programmers were initially skeptical of the value of collaboration in working on the same problem and thought it would not be an enjoyable process. However, results show that collaboration improved both their performance and their enjoyment of the problem solving process [Nosek1998].

In 1999 at the University of Utah, students in the Senior Software Engineering course participated in a structured experiment. The students were aware of the importance of the experiment, the need to keep accurate information, and that each person (whether in the control or experimental group) was a very important part of the outcome. All students attended the same classes, received the same instruction, and participated in class discussions on the pros and cons of pair programming. When asked on the first day of class, 35 of the 41 students (85%) indicated a preference for pair programming. (Later, many of the 85% admitted that they were initially reluctant, but curious, about pair programming.)

The students were divided into two groups; both groups were deliberately composed of the same mix of high, average, and low performers. Thirteen students formed the control group, in which all the students worked individually on all assignments. Twenty-eight students formed the experimental group, in which all worked in two-person collaborative teams; collaboratively, they completed the same assignments as the individuals. (The collaborative pairs also did additional assignments to keep the overall workload the same between the two groups.) All 28 of the students in the experimental group had expressed an interest in pair programming. Some of the students in the control group had actually wanted to try pair programming. It is important to note that before enrolling in this class, students had significant coding practice. Most students had industry or internship experience and had written small compilers, operating system kernels, and interpreters in other classes. Cycle time, productivity, and quality results were compared between the two groups

As reported [Cockburn+2000; Williams2000; Williams+2000], our experimental class produced quantitative results supporting the pair programming results in industry. The students completed four assignments over six weeks. Thirteen individuals and 14 collaborative pairs completed each assignment. The pairs passed, on average, 15% more of the automated postdevelopment test cases run by an impartial teaching assistant. The difference in quality levels is statistically significant.

The pair results were also more consistent, while the individuals varied more about the mean. Individuals intermittently didn't hand in a program or handed it in late; pairs handed in their assignments on time. This result can be attributed to a positive form of "pair pressure" the programmers put on each other. The programmers admitted to working harder and smarter on programs because they did not want to let their partner down. Individuals did not have this form of pressure and, therefore, did not perform as consistently.

We can also make another statement about the quality of pairs. The pairs not only wrote programs that were of higher externally visible quality, but their programs were consistently more than 20% shorter than their individual counterparts. Implementing functionality in fewer lines of code is commonly viewed as an indication of better design quality and lower projected maintenance costs [Boehm1981]. The individuals were more likely to produce "blob class" [Brown+1998] designs just to get the job done. The design from the collaborative teams exploited more of the benefits of object-oriented programming. Their classes demonstrated more encapsulation and had more cohesive classes with better class-responsibility alignment. The individuals tended to have fewer classes that had many responsibilities. The collaborative designs would, therefore, be easier to implement, enhance, and maintain.

The other piece of the economic equation is time. If pair programming does double the time, certainly it cannot be justified. Many people's gut reaction is to reject the idea of pair programming because they assume that there will be a 100% programmer-hour increase by putting two programmers on a job that one can do. The University of Utah students recorded how much time they spent on their assignments via a Web-based data recording and information retrieval system. After the initial adjustment period in the first program (the "jelling" assignment, which took approximately ten hours), the pairs spent on average only 15% more than the individuals. Additionally, after the first program, the difference between the times for individuals and for the pairs was no longer statistically significant, because the average was driven up significantly by two of the 13 pairs. The median amount of time spent by the individuals and the pairs was essentially identical. (As a side note, the pairs who spent the most amount of time also spent the most amount of time when they completed pre- and postexperiment programs individually.)

This still invites the obvious question: Why would we invest even an additional 15% on code development by introducing pair programming? The answer is because of the higher quality that is obtained and the resulting cost savings (and increased customer satisfaction) because of this higher quality. Typically, in systems test it takes between one-half [Humphrey1995] and two [Humphrey1997] workdays to correct each defect. Industry data reports that between 33 and 88 hours are spent on each defect found in the field [Humphrey1995]. When each defect saved during code development can save defect detection and correction times of between one-half and 88 hours, pair programming quickly becomes the cost-saving alternative [Williams2000].

We should also note that if time-to-market/cycle time is a prime motivator for you, pair programming can get the job done in about half the time. Could the same thing be done with two programmers working independently? Not likely. Increased communication and in tegration time would increase their time, as Brooks has told us for over a quarter of a century with his "Brooks's Law" [Brooks1975]. Additionally, the quality would not be as high.

Data with students is a start in convincing you about the improvements offered by pair programming. Descriptions of two industrial case studies follow.

William Wood of NASA Langley reports that a pair of programmers in 2001 reimplemented numerical analysis of wave propagation code that was originally developed in 1997. The individual programmer worked for six weeks to produce 2,144 lines of code. The pair worked for four weeks (eight programmer weeks) to implement the same functionality in 403 lines of code. It is very important to know that during these eight programmer weeks, the pair also wrote 463 lines of testing code, while the individual did not write any testing code, and that the pair was learning a new language, while the individual was very experienced in the language. Combining the pair programming and the extensive testing techniques, they have much higher confidence in the new code.

A technology company in India reports very impressive pair programming results. The prototype of a Voice over IP project was done without pairing. The actual project was done using pair programming. The actual project was much more complex because it had to deal with meeting Quality of Service parameters, scalability, uptime, and so on. The paired project showed significant increases in productivity and quality. The data is summarized in Table 4.1

Table 4.1. Comparison of India Technology Projects
  Project 1: Solo Programmers Project 2: Pair Programmers
Project size (KLOC) 20 520
Team size 4 12
Effort (person months) 4 72
Unit test defects 107 (5.34 defects/KLOC) 183 (0.4 defects/KLOC)
System integration defects 46 (2.3 defects/KLOC) 82 (0.2 defects/KLOC)



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net