Pair Programming Illuminated [Paperback]

Laurie Williams (Author), Robert Kessler (Author)

Book Description

ISBN-10: 0201745763 | ISBN-13: 978-0201745764 | Publication Date: July 8, 2002 | Edition: 1

Pair programming is a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. It produces a higher quality of code in about half the time than that produced by the summation of their solitary efforts. However, nothing is simple where people and personalities are involved--especially people who are accustomed to working alone. The leap to pair programming for a variety of software development projects is one that yields many benefits. However, it is also one that requires careful thought and planning.

Editorial Reviews

From the Back Cover

Pair programming is a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. It produces a higher quality of code in about half the time than that produced by the summation of their solitary efforts. However, nothing is simple where people and personalities are involved--especially people who are accustomed to working alone. The leap to pair programming for a variety of software development projects is one that yields many benefits. However, it is also one that requires careful thought and planning.

Written as instruction for team members and leaders new to pair programming and as an improvement guide for experienced pair programmers, Pair Programming Illuminated explains both the principles underlying this method and its best practices. The authors, drawing on their own extensive experience, explain what works and what does not, what should be emphasized and what should be avoided. Two case studies further illuminate pair programming in practice: one in the context of extreme programming (XP), with which it often is associated, and one linked to a more disciplined software engineering process.

Key topics include:

Principles for selecting partners

Practical advice, such as furniture set-up, pair rotation, and weeding out bad pairs

Seven habits of effective pair programmers

Special appendices include:

A pair programming tutorial

An economic analysis of pair programming

An introduction to test-driven development

With this book in hand, you will quickly discover how pair programming fits the needs of your own organization or project. You then will see exactly how to get started with this method, and how to do it right.

0201745763B06262002

About the Author

Laurie Williams has applied the XP methodology to various projects. She is an organizer of the main XP conferences held thus far.

Robert Kessler is a professor in the School of Computing at the University of Utah, from which he holds his Ph.D., and a past department chair. Bob has founded a number of technology companies and is on the board of several others.

0201745763AB08072002

See all Editorial Reviews

Product Details

• Paperback: 288 pages
• Publisher: Addison-Wesley Professional; 1 edition (July 8, 2002)
• Language: English
• ISBN-10: 0201745763
• ISBN-13: 978-0201745764
• Product Dimensions: 8.6 x 8 x 0.6 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 4.6 out of 5 stars  See all reviews (10 customer reviews)
• Amazon Best Sellers Rank: #980,626 in Books (See Top 100 in Books)

Customer Reviews

Most Helpful Customer Reviews

14 of 15 people found the following review helpful:

5.0 out of 5 stars Accurate, practical, October 13, 2002

By 

Maxim Masiutin (Chisinau, Republic of Moldova) - See all my reviews
(REAL NAME)   

Amazon Verified Purchase

This review is from: Pair Programming Illuminated (Paperback)

I was inspired by the book "Extreme Programming Explained" by Kent Beck and we started to use pair programming. Since that we had a lot of unanswered questions:
- how to spread the pair programming practice across our organization,
- how to argue with the people who did never try pair programming but was against it,
- how to overcome management resistance to pair programming,
- how to gain support and acceptance from our peers,
- how to organize workplace layout in details, how to rotate pairs ...
This book has answered all the questions.

The authors did the awesome homework analyzing lots of books related to project management, software development and human relations. You will find lots of references. However, the book contains only a few authors' own assertion. The authors prefer to base on someone else's books and publications, logically combining and deducing them.

The most valuable aspect of the book is that the authors have interviewed lots of Pair Programming experts, who gave the answers to most specific questions.

14 of 17 people found the following review helpful:

4.0 out of 5 stars How to choose the personalities to pair, August 20, 2002

By A Customer

This review is from: Pair Programming Illuminated (Paperback)

Despite the mythology associated with software development, very few programmers have ever worked alone. Most of us have worked in teams and even when not working as part of a formal team there were people we shared our coding problems with. In fact, when talking about coding, programmers are a gregarious group. Therefore, the only difference with pair programming is the formalization of the matching, where two programmers are "formally" paired to work on a single task.
The questions concerning the efficacy of pair programming generally involve getting the right two people grouped together. Given that they will share the same space, physical and intellectual, for approximately eight hours a day for the duration of the project, it is not hard to anticipate tiny personality differences growing into gear teeth that no longer mesh. The authors tackle this problem by going through examples of pairing all different skill levels. While nothing in human behavior is ever exact, they do set down logical reasons to explain why it is possible for all forms of pairing to work. However, I do think they were a little light on one of the possible pairings, namely the expert with the novice. In general, programming projects rely very heavily on the output of the expert, research has shown that in many cases major software projects were developed by surprisingly small groups of programming tigers. Therefore, very few companies are willing to reduce the output of a star by having them spend time doing what could be considered routine training. Furthermore, many experts are not very good at explaining how they do things to anyone, much less someone who may not know the basic syntax rules.
Novice-novice pairing is another where one finds it difficult to find reasons to justify ever doing it. You certainly could not trust the pair to create valuable code and if they reinforce each other's weaknesses, you could also see a reduction in their skill levels if they are paired. I don't agree with the authors when they say that a novice pair is better than a solo novice. In my opinion, the only convincing arguments they have for pairings are expert-expert, expert-average, average-average and average-novice.
The argument against pair programming is not that it doesn't lead to the faster solving of problems than if the two worked alone. Everyone who has coded has experienced those moments where they spent hours trying to track down a bug, only to show the problem code to another and have them solve it in a manner of seconds. The question has always been whether the pairing of programmers leads to solutions arrived at twice as fast and the answer to that question is no. Pair programming is more efficient than two working separately due to the fact that the quality of the solutions is higher. Given the complexity of the code and the length of time it will be subject to maintenance, even a slightly better solution arrived at by pair programming can justify putting the two heads on it. This point is made strongly and in my mind conclusively by the authors.
Pair programming is a fundamental part of the development strategy known as extreme programming or XP and there is some coverage of XP in the book. However, pair programming is something that can and should be done independent of XP, as properly used, it can lead to profound increases in productivity. Even though I don't always agree with the authors concerning their arguments as to when to use pair programming, overall they put forward a great deal of sound advice on how it can be used and what you will gain from it.

7 of 8 people found the following review helpful:

5.0 out of 5 stars I started a bit skeptical on pairing but now a believer..., December 7, 2002

By 

E. M. Maximilien (San Jose, CA USA) - See all my reviews

Amazon Verified Purchase

This review is from: Pair Programming Illuminated (Paperback)

I started a bit skeptical about pairing until I read this book. After completing the book I realized that I was thoroughly mistaking about my premature conclusions and comments on the topic.

This is a very thorough, interesting and entertaining book. After reading it from cover to cover, I realized that pair-programming is not only a good thing-in many instances for most software processes-but that it addresses a problem that many individual in our field suffers from-and I am a prime examplar of a programmer with some form of the symptoms of that problem:

General lack of social skills, or interest, for interacting, communicating and working in teams to create "good" large software... as well as sharing our knowledge without prejudice and with humility. Not too mention dealing with our not so small egos...

I also realized that in some sense, I have experienced (positively) some form of pair-programming without really knowing it. At the large software company where I work, we do spend a fair amount of time reviewing code and coaching, which reminds me of some of the tactics that is proposed in the book. Further, in a recent project I personally did spend a lot of time in a "coaching" role (as the lead) with the team... and the feedback I got from members of the team was only positive.

I am convinced now that my initial attitude and thoughts towards pairing was wrong and was based on misunderstanding and probably on recollections of "expert-novice" pairing that I had experienced a few times in the past; and which is singled out in the book as one instance where pairing might not work well. Further, my "soloist" programming background coupled with a more introverted personality does not help the matter. However, I do also realize that any decent software system (delivered in competitive business time and quality) has to be done by a team and is not a trivial endeavor-I speak from experience here. So breeding "soloist" programmers is not in the interest of the field nor is it for any company. Finally, as is indicated many times, pairing might also be a lot more fun.

I know now what changes I will be pushing for, in my next project.