- Information
- AI Chat
All I Really Need to Know about Pair Programming I Learned In Kindergarten
Computer Science & Programming (COSC 1306 )
Houston Community College
Preview text
All I Really Need to Know about Pair Programming I Learned In Kindergarten (submitted to Communications of the ACM)
Laurie A. WilliamsUniversity of Utah Robert R. KesslerUniversity of Utah lwilliam@cs.utah kessler@cs.utah Abstract All I Really Need to Know I Learned in Kindergarten By Robert Fulghum (Fulghum 1988) Share everything. Play fair. Don’t hit people. Put things back where you found them. Clean up your own mess. Don’t take things that aren’t yours. Say you’re sorry when you hurt somebody. Wash your hands before you eat. Flush. Warm cookies and cold milk are good for you. Live a balanced life – learn some and think some and draw and paint and sing anddance and play and work every day some. Take a nap every afternoon. When you go out into the world, watch out for traffic, hold hands and stick together. Be aware of wonder.
Introduction 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. As discussed below, use of this practice has been demonstrated to improve productivity and quality of software products. Additionally, based on a survey(Williams 1999) of pair programmers (hereafter referred to as “the pair programming survey"), 100% agreed that they had more confidence in their solution when pair programming than when they program alone. Likewise, 96% agreed that they enjoy their job more than when programming alone.
However, most programmers are long conditioned to performing solitary work and often resist the transition to pair programming. Ultimately, most triumphantly make this transition. This purpose of this paper is to aid programmers in becoming effective pair programmers. The transition and on-going success as a pair programmer often involves practicing everyday civility, as written about in Robert Fulghum’s poem above. Each of the poem lines (some adapted with poetic license) will be explored for the inherent lessons related to successful pair programming.
Pair Programming: Evidence of Success
Anecdotal and initial statistical evidence indicates pair programming is highly beneficial. Extreme Programming (XP), an emerging software development methodology, attributes great success to the use of “pair programming.” XP was developed initially by Smalltalk code developer and consultant Kent Beck with colleagues Ward Cunningham and Ron Jeffries. The evidence of XP’s success is highly anecdotal, but so impressive that it has aroused the curiosity of many highly-respected software engineering researchers and consultants. The largest example of its accomplishment is the sizable Chrysler Comprehensive Compensation system launched in May 1997. After finding significant, initial development problems, Beck and Jeffries restarted this development using XP principles. The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods, (Anderson 1998), went into production almost on schedule, and is still operational today. Additionally, programmers at Ford Motor Company, spent four unsuccessful years trying to build the Vehicle Cost and Profit System (VCAPS) using a traditional waterfall methodology. The XP developers successfully implemented that system in less than a year using Extreme Programming (Beck 1999).
XP attributes great success to the use of “pair programming.” All production code is written with a partner. XP advocates pair programming with such fervor that even prototyping done solo is scrapped and re-written with a partner. One key element is that while working in pairs a continuous code review is performed, noting that it is amazing how many obvious but unnoticed defects become noticed by another
The respondents of the pair programming survey gave overwhelming support for the technique. Says one: “I strongly feel pair programming is the primary reason our team has been successful. It has given us a very high level of code quality (almost to the point of zero defects). The only code we have ever had errors in was code that wasn’t pair programmed... we should really question a situation where it isn’t utilized.” Given these successes, let's review some principles of pair programming in the context of Fulghum’s poem.
Share everything.
In pair programming, two programmers are assigned to jointly produce one artifact (design, algorithm, code, etc.). The two programmers are like a coherent, intelligent organism working with one mind, responsible for every aspect of this artifact. One person is typing or writing, the other is continually reviewing the work. But, both are equal participants in the process. It is not acceptable to say or think things such as, “You made an error in your design.” or “That defect was from your part.” Instead, “We screwed up the design.” or, better yet, “We just got through test with no defects!” Both partners own everything.
Play fair.
With pair programming, one person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work. Even when one programmer is significantly more experienced than the other, it is important to take turns “driving,” lest the observer become disjoint, feel out of the loop or unimportant.
The person not driving is not a passive observer, instead is always active and engaged. “Just watching someone program is about as interesting as watching grass die in a desert (Beck to be published).” In the pair programming survey, approximately 90% stated that the main role of the person not typing was to perform continuous analysis, design and code reviews. “When one partner is busy typing, the other is
thinking at a more strategic level – where is this line of development going? Will it run into a dead end? Is there a better overall strategy? (Beck to be published).”
Don’t hit your partner.
But, make sure your partner stays focused and on-task. Doubtlessly, a benefit of working in pairs is that each is far less likely to “waste time” reading e-mail, surfing the web, or zoning out the window – because their partner is awaiting continuous contribution and input. Additionally, each is expecting the other to follow the prescribed development practices. “With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won’t... the chances of ignoring your commitment to the rest of the team is much smaller in pairs then it is when you are working alone (Beck to be published).”
Summarized in the pair programming survey, “It takes more effort because the pace is forced by the other person all the time; neither person feels they can slack off.” As each keeps their partner focused and on- task, tremendous productivity gains and quality improvements are realized.
Put things back where they belong.
The mind is a tricky thing. If you think about something enough, the brain will consider it a truth. If you tell yourself something negative, such as “I’m a terrible programmer,” soon your brain will believe you. However, anyone can control this negative self-talk by putting these thoughts where they belong, in the trash can, every time they start to creep into their brain. The surveyed pair programmers indicated that it was very difficult to work with someone who had a great insecurity or anxiety about their programming skills. They tend to have an “If I work with you, you might find out I’ve never coded with exceptions” defensiveness about them. Programmers with such insecurity should view pair programming as a means to improve their skill by constantly watching and obtaining feedback from another.
Don’t take things too seriously.
“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of Computer Programming (recently re-reported in Weinberg 1998) a quarter of a century ago, is essential for effective pair programming. According to the pair programming survey, excess ego can manifest itself in two ways, both damaging the collaborative relationship. First, having a “my way or the highway” attitude can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.
In The Psychology of Computer Programming (Weinberg 1998), a true scenario about a programmer seeking review of the code he produced is discussed. On this particular “bad programming” day, this individual laughed at himself because his reviewer found seventeen bugs in thirteen statements. However, after fixing these defects, this code performed flawlessly during test and in production. How different this outcome might have been had this programmer been too proud to accept the input of others or had viewed this input as an indication of his inadequacies. Having another to continuously and objectively review design and coding is a very beneficial aspect of pair programming. “The human eye has an almost infinite capacity for not seeing what it does not want to see... Programmers, if left to their own devices, will ignore the most glaring errors in their output -- errors that anyone else can see in an instant (Weinberg 1998)."
Conversely, a person who always agrees with their partner lest create tension also minimizes the benefits of collaborative work. For favorable idea exchange, there should be some healthy disagreement/debate. Notably, there is a fine balance between displaying too much and too little ego. Effective pair programmers hone this balance during an initial adjustment period. Ward Cunningham, one of the XP founders and experienced pair-programmer, reports that this initial adjustment period can take hours or days, depending on the individuals, nature of work and their past experience with pair-programming.
Say you’re sorry when you hurt somebody while moving furniture.
In the pair programming survey, 96% of the programmers agreed that appropriate workspace layout was critical to their success. The programmers must be able to sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and mouse. In the diagram below (from (Beck 1999)), layouts to the right are preferable to layouts on the left. Extreme programmers have a “slide the keyboard/don't move the chairs” rule.
Effective communication, both within a collaborative pair and with other collaborative pairs, is paramount. Without much effort, programmers need to see each other, ask each other questions and make decisions on things such as integration issues, lest these questions/issues are often not discussed. Programmers also benefit from “accidentally” overhearing other conversations to which they can have vital contributions. Separate offices and cubicles can inhibit this necessary exchange. "If any one thing proves that psychological research has been ignored by working managers, it's the continuing use of half partitions to divide workspace into cubicles. ... Like many kings, some managers use divide-and-conquer tactics to rule their subjects, but programmers need contact with other programmers. (Weinberg 1998)”
Pair programmers take aggressive action on improving their physical environment, by taking matters into their own hands (armed with screwdrivers).
Wash your hands of skepticism before you start.
independent work. In their XP experience, the majority of the defects they found could be traced back to a time when a programmer worked independently. In fact, in their Chrysler Comprehensive Compensation project during the last five months before first production, the only defects that made it through unit and functional testing were written by someone programming alone. In re-writing, the author must undergo the customary continuous review of the work, which identifies additional defects.
The decision to flush or to review work done independently can be made by a pair of programmers, or the choice may be encouraged, as it is with Extreme Programming. However, it is important to note that none of the programmers surveyed incorporated work done independently without reviewing it.
Warm cookies and cold milk are good for you.
Because pair programmers do keep each other continuously focused and on-task, it can be a very intense and mentally exhausting. Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming. During the break, it is best to disconnect from the task at hand and approach it with a freshness when restarting. Suggested activities: checking email, making a phone call, surfing the web, eating warm cookies and drinking cold milk.
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Communicating with others on a regular basis is key for leading a balanced life. “If asked, most programmers would probably say they preferred to work alone in a place where they wouldn't be disturbed by other people (Weinberg 1998).” But, informal discussions with other programmers – the one you are paired with or any other – allow for effective idea exchange and efficient transfer of information. For example, The Psychology of Computer Programming (Weinberg 1998) discusses a large university computing center. A common space with a collection of vending machines was in the back of the room. Some serious-minded students complained about the noise in this common space, and the vending
machines were moved out. After the vending machines were removed and signs urging quiet had been posted, a different complaint abounded – not enough computer consultants! Suddenly, the lines for the computer consultant wound around the room. The cause of the change: the informal chat around the vending machines had consisted of idea exchange and information transfer between the mass of programmers. Now, all this discussion had to be done with the relatively few consultants. (Sadly, the vending machines were never moved back in.)
Take a break from working together every afternoon.
It’s certainly not necessary to work separately every afternoon. But, according to 50% of the surveyed programmers, it is acceptable to work alone 10-50% of the time. Many prefer to do experimental prototyping, tough, deep-concentration problems, and logical thinking alone. Most agree that simple, well-defined, rote coding is more efficiently done by a solitary programmer and then reviewed with a partner.
When you go out into the world, watch out for traffic, hold hands and stick together.
With pair programming, the two programmers become one. There should be no competition between the two; both must work for a singular purpose, as if the artifact was produced by a singular good mind. Blame for problems or defects should never be placed on either partner. The pair needs to trust each other’s judgement and each other’s loyalty to the team.
Be aware of the power of two brains.
Human beings can only remember and learn a bounded amount. Therefore, they must consult with others to increase this bounded amount. When two are working together, each has their own set of knowledge and skills. A large subset of this knowledge and these skills will be common between the two, allowing them to interact effectively. However, the unique skills of each individual will allow them to
pair programmer must accept ownership of their partner’s work and, therefore, be willing to constructively express criticism and suggested improvements.
The transition to pair programming takes the conditioned solitary programmer out of their “comfort zone.” However, the potential for achieving results impossible by a single programmer makes this a journey to greatness.
Bibliography Anderson, A., Beattie, Ralph, Beck, Kent et al. (1998). Chrysler Goes to "Extremes". DistributedComputing. October 1998: 24-28.
Beck, K., Cunningham, Ward (1999). Extreme Programming Roadmap, c2/cgi/wiki?ExtremeProgramming. 1999. Beck, K. (to be published). Embrace Change: Extreme Programming Explained, Addison-Wesley. Constantine, L. L. (1995). Constantine on Peopleware. Englewood Cliffs, NJ, Yourdon Press. DeMarco, T., Lister, Timothy (1977). Peopleware. New York, Dorset House Publishers. Fulghum, R. (1988). All I Really Need to Know I Learned in Kindergarten. New York, Villard Books. Hargrove, R. (1998). Mastering the Art of Creative Collaboration, McGraw-Hill. Kraut, R. E., Streeter, Lynn A. (1995). “Coordination in Software Development.” Communications of theACM March 1995(March 1995): 69-81.
Nosek, J. T. (1998). The Case for Collaborative Programming. Communications of the ACM. March 1998: 105-108. Weinberg, G. M. (1998). The Psychology of Computer Programming Silver Anniversary Edition. NewYork, Dorset House Publishing.
Weinberg, G. M. (1999). Egoless Programming. IEEE Software. January/February: 118-120. Williams, L. (1999). Pair Programming Questionnaire, http:\limes.cs.utah.edu/questionnaire/questionnaire. 1999.
All I Really Need to Know about Pair Programming I Learned In Kindergarten
Course: Computer Science & Programming (COSC 1306 )
University: Houston Community College
- Discover more from:
