DOC PREVIEW
UNCC ECGR 4101 - How Pair Programming Really Works

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

feature50 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 74 5 9 / 10 / $ 2 6 . 0 0 © 2 0 1 0 I E E EAs a dictionary definition, I’d say that pair programming is a technique in which two people sit down, literally side by side, and write a pro-gram at the same computer. When Kent Beck originally coined the term, he described two programmers working at different levels of ab-straction.1 Laurie Williams and Robert Kessler made this idea more concrete, using the meta-phor of one programmer being the “driver” and the other the “navigator.”2 In this metaphor, the driver controls the keyboard and focuses on the immediate task of coding, and the navigator acts as a reviewer, observing and thinking about more strategic architectural issues. My own experience as a developer using pair programming is that it isn’t just a technique where one person programs and the other per-son watches. Both programmers work closely to-gether, chatting the whole time, jotting down re-minders of things to do, and pointing out pieces of code on the screen. (One of the clichés of pair programming is that if you’re doing it right, your screen should be covered with greasy finger-marks by the end of the day.) Programmers take turns at the keyboard, usually swapping over with a phrase like, “No, let me show you what I mean.”Jan Chong and Tom Hurlbutt confirmed this view of successful pair programming after spend-ing several months on an ethnographic study of professional developers who use pair program-ming in their daily work.3 They found that pro-grammers tended to work together on the same facet of a problem almost the whole time and swap between tactical and architectural levels as a pair. Similar ethnographic studies by Sallyann Bryant and her colleagues4 and Stephan Salinger and his colleagues further confirmed this.5Of course, not all attempts at pair program-ming have been successful—Matt Stephens and Doug Rosenberg, for example, reported unfa-vorably on their experiences.6 However, what they described is a caricature of the driver- navigator metaphor, with one programmer firmly in control and the other sitting quietly, doing little. Such misunderstanding shows that we can’t take a claim that developers are pair programming at face value; they might not be doing what experi-enced and effective pair programmers actually do.Pair programming has generated considerable controversy: some developers are enthusiastic about it, almost evangelical; others are dubious, even hostile. However, a large factor in this controversy is that programmers label a wide variety of practices under the “pair programming” umbrella. Thus, before our community can sensibly discuss how pair programming works, we first need to es-tablish exactly what it is.Pair programming isn’t always successful, and recent studies cast doubt on the “driver-navigator” metaphor. Four mechanisms can improve pair programming performance. Stuart Wray, Royal School of SignalsHow Pair Programming Really WorksprogrammingShare your comments at http:// computingnow. computer.org/wray.January/February 2010 I E E E S O F T W A R E 51This kind of misunderstanding also casts doubt on the many attempts to assess pair pro-gramming’s effectiveness. (Tore Dybå and his colleagues provide a very nice summary of this experimental work.7) If the subjects of these ex-periments did different things, can we really com-pare their results? And if they weren’t doing what successful pair programmers do in commercial practice, can we apply their findings to commer-cial development?In this article, I advance four mechanisms prompted by my own experience of pairing in both agile and non-agile development. These mechanisms explain a large part of what suc-cessful pair programmers do. Of course, this is only the beginning: you might have experiences that confirm or contradict my suggestions. What have I missed? I hope you’ll contribute to the dis-cussion of these issues on the Web site (http:// computingnow.computer.org/wray).Mechanism 1: Pair Programming ChatAround 1980, as computer science undergradu-ate students at the University of Cambridge, my friends and I noticed a strange phenomenon that we called expert programmer theory. When one of us had trouble getting our programs to work, we’d describe the nonfunctioning state of our code to each other over coffee. Quite often, we’d real-ize in a flash what was wrong and how to solve it. These epiphanies were quite independent of the other person having any real understanding of our problems—the listener often seemed little wiser about the subject.Since then, I’ve found this phenomenon is well known to professional developers, and sometimes described in textbooks and research papers. For example, Brian Kernighan and Rob Pike recom-mended explaining problems aloud, even to a stuffed toy,8 a practice that John Sturdy called the rubber-plant effect.9 Part of pair programming’s effectiveness is presumably due to this effect be-ing continually triggered: as one programmer gets stuck, the back-and-forth chat serves to unstick them in the same way as solo programmers talk-ing about their problems out loud. However, this raises the question of whether any type of speak-ing will help or whether something specific is needed.Research on “self-explanation” by Michelene Chi and others throws some light on this ques-tion. Chi and her colleagues described a study that tested a control group of students before and after they received a textbook explanation to read.10 They tested another group in the same way, but encouraged the students to explain the textbook out loud and “fill in the gaps” for themselves. The self-explainers learned significantly more than the control group, and those who explained the most improved the most. The researchers also prompted the students for their explanations; they weren’t just left to their own devices. In particular, they were “prompted for further clarification by the experi-menter if what they stated was vague.”10This brings me back to an often-neglected as-pect of the


View Full Document

UNCC ECGR 4101 - How Pair Programming Really Works

Documents in this Course
Load more
Download How Pair Programming Really Works
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view How Pair Programming Really Works and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view How Pair Programming Really Works 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?