Customer Reviews

Pair Programming Illuminated

5 star:		(6)
4 star:		(4)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

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.

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.

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.

A well-rounded discussion of pair programming, this book presents not only where pair programming excels, but also where the problems lie. Whether you are looking for a sales pitch, implementation advice, or statistical data from pair programming studies, the book contains useful information for project managers, technical leads, and developers alike.

Part One covers general information about pair programming. It dispels some of the fear and uncertainty that revolves around the practice (myths) and highlights some of the positive aspects that can be derived (synergistic behaviors). It includes a chapter titled "Overcoming Management Resistance to Pair Programming" which lists achievable goals that any project manager would wish for. In addition, there's a short chapter on selling pair programming to reluctant peers. But the authors warn that it is probably best to use a pyramid marketing approach and just let the advocates sell it for you versus forcing it on staff. Part One closes with a list of problems to avoid when implementing pairing.

Part Two explains in less than 30 pages how to implement pair programming from the workspace layout to "Tips 'n Tricks" for making it work better. If read and applied carefully, this last chapter may help the developer looking for implementation advice to save a failing pair programming attempt. That alone makes this book a worthwhile read!

Part Three spans close to half of the book and walks through the various pairings that might occur when you have different technical abilities (expert, average, novice), sex, race, and attitudes involved in the process. Each of the technical ability pairings is examined with both positive and negative aspects highlighted. Relevant anecdotal information from experienced pair programmers is also included.

Part Four looks at pair programming as part of a software process, in particular, Extreme Programming (XP) and the Collaborative Software Process (CSP). The chapter on XP reviews the process in 10 pages and explains why the authors believe pair programming is an integral part of the process. The CSP chapter is derived from the author Laurie Williams' dissertation and is an extension of XP and Watt's Humphrey's Personal Software Process (PSP).

Part Five closes the book out with edge case information on pair programming in a distributed environment, using it in an educational setting, the continued relevance of code inspections, and more. Also included is a "Seven Habits of Effective Pair Programmers" list which couples nicely with the "Tips 'n Tricks" chapter in Part Two.

You will also find useful information in the appendices. There is a Pair Programming Tutorial designed to lead people through a half-day pair programming exercise. An economic analysis of an empirical study conducted at the University of Utah looks at supporting data from both an efficiency and economic perspective.

Pros
* Covers pair programming from multiple perspectives.
* Advises on improving pair programming sessions.
* Contains empircal data supporting the practice.

Cons
* Part Three could have been abbreviated but is easily scanned for relevant information.

This is a great book that not only covers what is good about pair programming, but also the mechanics for how to do it. Many books of this type fall into the trap of selling the technique at every chance they get (sometimes it seems just to fill pages).

This book keeps the sales pitch to a minimum and when they do tout the benfits of pair programming they do so in a consise and informative manner.

The mechanics for performing pair programming are beautifully covered with both humor and practical tips for success. Many books of this type describe implementation in terms of total success. This book doesn't fall into that trap, but discusses the pitfalls that can acompany pair programming.

I highly recommend this book for those who are actively practicing or attempting to introduce pair programming into their organization.

Since almost three years, I am struggling to find new better ways to make Pair-Programming a regular practice at my workplaces. I found in the book answers in Chap. 4 "Overcoming Management Resistance to PP" and Chap. 5 "Gaining support and acceptance from your peers" very interesting!
In fact, the book brings numbers and rationale for the serious case of Pair-Programming practice.
Pair programming typical cases are shown and discussed thoroughly. It helps for doing pair programming and coaching newbies and more experimented.
Thanks to the authors!

Finally, "full disclosure". Instead of assertions that pair programming must be good, everyone should do it, and "just get going", Williams and Kessler tell us honestly that pair programming is "simply not for all" and requires continous maintenance. And they admit they "don't know yet" how pair programming might or might not replace formal code reviews. (Rather honestly, they admit that in a context where most people don't do any code reviews, pair programming could help a bit.)

With that out of the way, Pair Programming Illuminated really does illuminate: explanations and examples of how to start pair programming, what to expect, and how to address problems. Practicality instead of magic. Well worth the read.

Last session I started getting students to apply pair-programming in
the context of our second year group software engineering project, but
the take up of the practice was rather limited, mostly because they
needed more guidance on how to organize it. This book provides lots
of useful advice on managing pair working and it's really easy to find
your way around and get to the information you want - and you
certainly come away from reading it believing it will deliver its
promises and wanting to try it: the authors' enthusiasm is
infectious. Although I have read it from an educator's viewpoint, the
pitch to industrial software developors looks equally strong, with
lots of positive feedback from practitioners who have dealt with
the problems that arise and made it work for them. From a teaching
perspective, it's not a book you are going to recommend as a main
text, but it is essential background reading for the students and you
and your teaching assistants need a copy to hand while getting the
practice functioning in the lab. A good read and a great addition to
the current set of software engineering texts.

This book is simply excellent. I found it on the shelf in our office, so I grabbed it and read it mostly on the train commuting to work. I enjoyed reading it from the front cover to the end.

This book is purely focused of pair programming, so if you have not had an exposure to extreme programming I recommend you read "Extreme Programming Explained: Embrace Change" by Kent Beck and Cynthia Andres first.

We started practicing XP in our development team. Our manager got several copies of XP Explained book for us. As I have already read it, I read another book about XP: "Extreme Programming Applied: Playing to Win." After that, I found this one and let me tell you, it is a real treasure. Some of the times, when I came to the office and we had the stand-up meeting, we discussed how we could make XP work better for us. There were so many things from real life that were in this book!

This book is very easy to read and very true to practices of pair programming. You won't be disappointed.

As the title suggests, Pair Programming Illuminated casts light on many of the frequently asked questions about pair programming. This very readable book helps you to understand why pair programming works, how to implement it, and when to consider not using it. Statements about pair programming are supported by data as well as stories by the authors and other practioners of pair programming. Buy this book if you want to understand pair programming better, implement pair programming in your team, or explain pair programming's benefits to someone else.