What do you think?
Rate this book
Pair Programming Illuminated
-- Written as instruction for pair programming newbies, and practical improvement tips for those experienced with the concept.-- Explores the operational aspects and unique fundamentals of pair programming; information such as furniture set-up, pair rotation, and weeding out bad pairs.
-- Special section enumerates the Seven Habits of Effective Pair Programmers.
At face value, pair programming appears to be a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. If it was as simple as plopping two skilled programmers at one desktop, there would be no need for this book. However, there are people and personalities involved, and these people are accustomed to programming alone. Pair programming offers significant benefits: quality is increased, time is saved, morale is improved, trust and teamwork grow, knowledge is shared, and learning is enhanced. However, before any pair programming can take place, participants have to accept a new way of thinking. In Pair Programming Illuminated, Laurie Williams and Robert Kessler help you fight through the exceptions, gain collective acceptance of this approach, and experience remarkable success with it. Two case studies show pair programming in practice using Extreme Programming and Collaborative Software Process as methods.
-- Special section enumerates the Seven Habits of Effective Pair Programmers.
At face value, pair programming appears to be a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. If it was as simple as plopping two skilled programmers at one desktop, there would be no need for this book. However, there are people and personalities involved, and these people are accustomed to programming alone. Pair programming offers significant benefits: quality is increased, time is saved, morale is improved, trust and teamwork grow, knowledge is shared, and learning is enhanced. However, before any pair programming can take place, participants have to accept a new way of thinking. In Pair Programming Illuminated, Laurie Williams and Robert Kessler help you fight through the exceptions, gain collective acceptance of this approach, and experience remarkable success with it. Two case studies show pair programming in practice using Extreme Programming and Collaborative Software Process as methods.
256 pages, Paperback
First published February 6, 1990
4 people are currently reading
95 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 8 of 8 reviews
August 14, 2018
* What is pair programming ?
* Does my team need it ?
* Is the project right for it ?
* Will it improve the quality ?
* Will it delay things and delivery ?
* How tough is it to switch ?
* How to decide the pairs ?
All these questions have been aptly answered in this book. A very detailed introduction to pair programming.
* Does my team need it ?
* Is the project right for it ?
* Will it improve the quality ?
* Will it delay things and delivery ?
* How tough is it to switch ?
* How to decide the pairs ?
All these questions have been aptly answered in this book. A very detailed introduction to pair programming.
April 22, 2011
This book has a nice mix of instruction, anecdotal examples, and research. It's definitely recommended for those that want to learn more about the practice of pair programming specifically.
April 27, 2021
Pair programming is underrated, really underrated - It reminds me of functional programming, old and not popular and underrated. Did I mention that it is underrated?
Bad things: The book lacks some charts that are available in the research paper by Laurie Williams but we got the tables so it is not that bad. After reading Martin Fowler post "On pair programming" it also seems that book despite being not so long to read, could have 20-30 pages less and still it feels like Martin Fowler post is somehow complementary although it lacks the research behind it.
Everything else is just great, I appreciate the chapter about remote pair programming, different pairing setups discussions, myths, the research behind the book. I was about to give the book 4/5 but we as engineering community should appreciate the economic justification for pair programming which can be found in the book (specifically in the appendix). All in all after reading this you may end up asking yourself "Why the people don't pair-program by default?" 5/5.
Bad things: The book lacks some charts that are available in the research paper by Laurie Williams but we got the tables so it is not that bad. After reading Martin Fowler post "On pair programming" it also seems that book despite being not so long to read, could have 20-30 pages less and still it feels like Martin Fowler post is somehow complementary although it lacks the research behind it.
Everything else is just great, I appreciate the chapter about remote pair programming, different pairing setups discussions, myths, the research behind the book. I was about to give the book 4/5 but we as engineering community should appreciate the economic justification for pair programming which can be found in the book (specifically in the appendix). All in all after reading this you may end up asking yourself "Why the people don't pair-program by default?" 5/5.
December 29, 2014
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.
Published in the online Journal of Object Technology, reprinted with permission.
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.
Published in the online Journal of Object Technology, reprinted with permission.
December 30, 2014
The book was very easy to read and provides a straightforward explanation of why you would want to use pair programming. I haven't formally used pair programming in my work environment, but some of my co-workers are considering it. I found the book to be a helpful explanation of some of the benefits and problems associated with pair programming. I also liked some of the real world case studies and experiments that the authors did with their university classes and a few companies.
The one downside of the book is that some of the material presented does seem to be a bit obvious and there is some repetition between the chapters.
The one downside of the book is that some of the material presented does seem to be a bit obvious and there is some repetition between the chapters.
May 6, 2013
This book had a lot of background information on pairing, but I did not find the sort of extremely concrete, nuts-and-bolts methodology I was looking for.
October 31, 2014
This book does a great job of showing how something that seems so easy is actually really hard and then makes it easy again.
Displaying 1 - 8 of 8 reviews