This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Pair Programming Paper
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Economics. A recent controlled experiment found only a small development cost for adding the second person. However, the resulting code also had fewer defects. The defect removal savings should more than offsets the development cost increase.
This paper sites IBM's finding that defects released to end-users cost an average of $8000 to fix. The lower defect rate more than makes up the slightly higher cost of development. Another quote: we zoomed through QA with hardly a hitch. Everyone, myself included, was amazed that it didn't take weeks to debug, especially given that one of the trees had recently spent SIX WEEKS in QA hell. It was obvious that the pairs had dramatically reduced the defect rate.
Other effects of pair programming:
Pair relaying ... pairs consistently report that they solve problems faster, and that it is different from improving design quality, or detecting typing errors, or brainstorming. By "problem solving", we refer to when the two are puzzled as to why something doesn't work as expected, or simply can't figure out how to go forward.
...I encouraged the developers to think out loud (what Ward Cunningham calls reflective articulation). This did the trick. They actually began to work together, not just take turns coding...
Line of sight learning... successful apprenticeship environments is that the novice work in a "line of sight" of the expert, that expertise is transmitted, in part, through the ongoing visual (and auditory) field. They describe successful apprenticeship learning in both tailors and Navy signalmen where "line of sight" is available. The beginner explicitly picks up skills from hearing and/or seeing the expert.
Use Expert In Earshot when novices are not learning good techniques and habits very well, but you don't want to turn the expert into a full-time teacher. Put the expert or leader in the same workspace as the more novice workers, so that the novices can learn by watching and listening, while the expert does his or her usual work....
Note also that experts can learn from their non-expert partners:
I was sitting with one of the least-experienced developers, working on some fairly straightforward task. Frankly, I was thinking to myself that with my great skill..., I would soon be teaching this young programmer how it's really done. We hadn't been programming more than a few minutes when the youngster asked me why I was doing what I was doing. Sure enough, I was off on a bad track. I went another way. Then the whippersnapper reminded me of the correct method name for whatever I was mistyping at the time. Pretty soon, he was suggesting what I should do next...
Previous Topic
