Home > Store > Programming > General Programming/Other Languages

larger cover

Add To My Wish List

Pair Programming Illuminated

Register your product to gain access to bonus material or receive a coupon.

  • Description
  • Downloads
  • Reviews
  • Sample Content

Product Author Bios

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

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

    Supplements

    Supplements

     

    Customer Reviews

    15 of 16 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(What's this?)
    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... Read more

    Help other customers find the most helpful reviews 
    Was this review helpful to you? Yes No


    15 of 18 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... Read more
    Help other customers find the most helpful reviews 
    Was this review helpful to you? Yes No


    8 of 9 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 
    Amazon Verified Purchase(What's this?)
    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... Read more

    Help other customers find the most helpful reviews 
    Was this review helpful to you? Yes No


    Share your thoughts with other customers:
     See all 11 customer reviews...

    Online Sample Chapter

    Overcoming Management Resistance to Pair Programming

    Index

    Click below to download the Index file related to this title:
    Index

    Preface

    This purpose of this book is to provide you with lots of information on pair programming. If you are already pairing, then the book will give you additional insights and techniques to make your pairing even more successful. We answer many of the questions and concerns that you may have about using the technique.

    In Section One, our aim is for you to gain greater understanding about pair programming. We'll describe the technique and will be looking at pair programming from many perspectives . . . from those who want to try and those who would rather not try, from those who are employees trying to convince their managers to let them try and those who are managers who are trying to convince their employees to try.

    In Section Two, we deal with some operational details of pairing--like furniture and hints and tips for daily operation. We discuss the importance of pair rotation and how that can lead to better knowledge management.

    In Section Three, we explain benefits and shortcomings of many different kinds of pairs and the context when each kind of pair works best. We offer ideas to help enhance the pairing and solutions for most problem pairings. Unfortunately, not all pairs will work and we provide ways to recognize the potential problems before they happen.

    Section Four gives two case studies of pair programming in different methodologies. The first describes pairing in Extreme Programming (XP), while the second discusses the Collaborative Software Process (CSP). In both cases, pair programming is an essential ingredient to success.

    We conclude in Section Five with some future directions and by enumerating Seven Habits of Effective Pair Programmers.

    Who Should Read This Book

    We've written this book for software development team members and their managers. When we use the term "software development team," it goes beyond those who write production code. For example, this book is certainly appropriate for team leaders and coaches, GUI designers, architects, and QA folks. This book was also written for educators who would like to try pair programming with their students. Depending upon your role, may we suggest the following process for reading this book:

  • Software developers and team leaders/coaches who haven't tried pair programming yet will find Section One very useful. All should read Chapters 1-3 very carefully. If you are trying to convince your manager to transition to pair programming, Chapter 4 will be helpful. If you would like to convince your peers to give pair programming a shot, Chapter 5's for you. If you are currently being forced into pair programming, Chapter 6 will give you some guidance. Then, you can move on to the chapters in Section Two to get into some of the more operational issues you will need to deal with in a transition to pair programming. Chapter 27, the Seven Habits of Effective Pair Programmers will get you started on the right track. Appendix A, the Pair Programming Tutorial, can be used to help you transition a team or convince a team to take the pair-programming plunge.
  • Software developers and team leaders/coaches who are currently doing pair programming should start out skimming Chapters 1-3. Much of this will be review for you, but you may pick up some additional insight. Then, you can move on to the chapters in Section Two to get into some of the more operational issues. Section Three will be particularly important in guiding you to choosing the best pair for the task at hand. Chapter 27, the Seven Habits of Effective Pair Programmers, will be a good grand finale for you. How many of these habits do you practice? Appendix D provides information about including Test-First Design with pair programming.
  • QA personnel might be wondering how to handle a development team that has or plans to practice pair programming. Chapters 1-4 will give you a solid understanding of the technique and its benefits. Chapters 10 and 26 also discuss the possibility of pair programming as a substitute to code inspections. Appendix D discusses the composition of pair programming and a testing technique called Test-First Design.
  • Managers should start out by reading the first four chapters and Chapter 7 of Section One. Then, if you are trying to convince a team to try pair programming, Chapter 6 will be helpful for you. Chapter 6 advises you to run a Pair Programming Tutorial, which is outlined in Appendix A, with your team. Section Two provides information about operational issues of pair programming. Chapter 26 provides information on some directions pair programming may lead to.
  • Educators should read the first four chapters of Section One to gain a good basic understanding of the technique. Chapters 8, 10 and 11 will provide some tactical information about your students. Depending upon the skill level and mix of your students, you can choose some chapters in Section Three. Chapter 26 should appeal to your academic research interests. Chapter 27 provides good information to share with your students. Appendix C was written with you in mind, and provides some sound tactical advice for using pair programming in your classroom.
  • Who Wrote This Book

    The authors of this book are Laurie Williams and Bob Kessler. Laurie has a BS in Industrial Engineering from Lehigh University, an MBA from Duke, and a PhD in Computer Science from the University of Utah. She has also worked for IBM for nine years in various manufacturing, software development and management positions. She is currently an Assistant Professor in the Computer Science department at North Carolina State University. Bob has a BS, MS and PhD in Computer Science from the University of Utah. He has founded several companies and is on the board of several others. He is currently a full professor in the School of Computing at the University of Utah.

    As we're sure you surmise, the great benefit that comes from pair programming comes from the social interactions between the partners. Thus, as you might expect, there are social issues involved. Although not trained sociologists, both of us have many years of experience in software development. Thus, our views on the social interactions are grounded in our management experience and provide our fundamental basis for solving the various problems and issues.

    You might be wondering how we assimilated all the information in this book. We've done pair programming ourselves. We performed an extensive, formal experiment of pair programmers versus solo programmers, which yielded groundbreaking results. We've observed professional and student pair programmers. We've talked with or presented to thousands of experienced pair programmers, those considering pair programming and anti-pair programmers. We've also done two extensive surveys of professional pair programmers. We've heard lots of wonderful endorsements of pair programming, and we've heard every reason in the book why it won't work. We'll be quoting statistics from these surveys, presenting data gathered in our studies, and relaying lots of information from all these sources and our own experiences.



    0201745763P03262002

    Table of Contents



    Preface.


    Who Should Read This Book.


    Acknowledgments.

    I. GAINING UNDERSTANDING.

    1. Introduction.

    To Pair …

    … or Not to Pair, This Is the Question.

    A Fly on the Wall.

    A Pair Programming Timeline.

    Some Words of Caution.

    2. The Seven Myths of Pair Programming.

    Myth 1: It will double the workload with two doing the work one can do.

    Myth 2: I'll never get to work alone. I couldn't stand that!

    Myth 3: It will work well only with the right partner.

    Myth 4: Pair programming is good for training. But, once you know what you're doing, it is a waste of time.

    Myth 5: I'll never get credit for doing anything. I'll have to share all the recognition with my partner.

    Myth 6: The navigator finds only syntax mistakes. How boring is that! Compilers can do that better than humans can anyway.

    Myth 7: The only time I ever get any real work done is when I'm alone. Now, I'll never get anything done! Pair programming would drive me crazy.

    3. The Seven Synergistic Behaviors of Pair Programming.

    Behavior 1: Pair Pressure.

    Behavior 2: Pair Negotiation.

    Behavior 3: Pair Courage.

    Behavior 4: Pair Reviews.

    Behavior 5: Pair Debugging.

    Behavior 6: Pair Learning.

    Behavior 7: Pair Trust.

    4. Overcoming Management Resistance to Pair Programming.

    Motivations.

    Goal: I want to complete my projects on time with high-quality code.

    Goal: I want to reduce my risk of losing a key person.

    Goal: I want my employees to be happy.

    Goal:I want to reduce the amount of time it takes to train a new person.

    Goal:I want my teams to work well together and to communicate more effectively and efficiently with each other.

    5. Gaining Support and Acceptance from Your Peers.

    6. Transitioning to Pair Programming by Choice.

    Green and Hevner's Findings.

    Advice for Management.

    Advice for Programmers.

    7. Problem, Problems.

    Dependency.

    Scheduling.

    The Ever-Popular Expert.

    Colocation.

    Noise and Facility Considerations.

    Concentration.

    Disagreements.

    Overconfidence.

    Rushing.

    Skill Imbalances.

    Simply Not for All.

    Summary: Maintenance Required.

    II. GETTING STARTED WITH PAIR PROGRAMMING.

    8. Workplace Layout.

    The Basic Needs.

    Some Suggested Workplace Enhancements.

    Interpair Communications.

    Development Environments.

    Noise Considerations.

    One Last Thing.

    9. Pair Rotation: Communication, Knowledge Management, and Training.

    Pairing with the Right Partner.

    Partner Assigning Logistics.

    Pair Rotation and Knowledge Management.

    Pair Rotation and Training.

    Reprisal: Pair Rotation.

    10. Other Issues to Consider.

    Performance Appraisals.

    Group Size.

    Quality Assurance.

    Functional and System Testing.

    Maintaining and Enhancing Code.

    11. Tips 'n Tricks.

    III. PAIR PROGRAMMING PARTNER PICKING PRINCIPLES.

    12. Expert-Expert Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    13. Expert-Average Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    14. Expert-Novice Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    15. Novice-Novice Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    16. Extrovert-Extrovert Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    17. Extrovert-Introvert Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    18. Introvert-Introvert Pairing.

    Intent.

    Characteristics of Success.

    Challenges.

    Personal Scenarios.

    19. Gender Nonissue.

    Issue.

    What This Is About.

    If There Are Problems.

    Personal Scenarios.

    20. Culture Nonissue.

    Issue.

    What This Is About.

    If There Are Problems.

    Personal Scenarios.

    21. The Professional Driver Problem.

    Root Causes.

    General Form.

    Refactored Solution.

    Personal Scenarios.

    22. “My Partner Is a Total Loser” and Other Excess Ego Problems.

    Root Causes.

    General Form.

    Refactored Solution.

    Personal Scenarios.

    23. “My Partner Is SO Smart” and Other Too Little Ego Problems.

    Root Causes.

    General Form.

    Refactored Solution.

    Personal Scenarios.

    IV. CASE STUDIES OF PAIR PROGRAMMING IN A SOFTWARE PROCESS.

    24. Pair Programming in a Software Process Case Study: Extreme Programming (XP).

    A Life-Cyle Evolution.

    Along Comes XP.

    Requirements Definition.

    System and Software Design.

    Code Implementation and Unit Testing.

    Acceptance Testing.

    XP Needs Pair Programming.

    25. Pair Programming in a Software Process Case Study: Collaborative Software Process (CSP).

    CSP Overview.

    Focus Area 0: Baselining Your Process.

    Focus Area 1: Quality Management.

    Focus Area 2: Project Management.

    Summary.

    V. IN CLOSING.

    26. Moving Ahead, Going Beyond.

    Triplets.

    Multidisciplinary Pairs.

    Code Inspections Obsolete?

    Projection Screens.

    Distributed Pair Programming.

    Pair Learning.

    27. Seven Habits of Effective Pair Programmers.

    Habit 1: Take Breaks.

    Habit 2: Practice Humility.

    Habit 3: Be Confident/Be Receptive.

    Habit 4: Communicate.

    Habit 5: Listen.

    Habit 6: Be a Team Player.

    Habit 7: Hone the Balance between Compromise and Standing Firm.

    Finale.

    Appendix A: Pair Programming Tutorial.

    Appendix B: An Economic Analysis of Pair Programming.

    Appendix C: Pair Programming in the Classroom.

    Appendix D: An Introduction to Test Driven Development.

    Index.

    Downloadable Sample Chapter

    Click below for Sample Chapter(s) related to this title:
    Sample Chapter 4

     
    Buy

    Book  $34.99  $27.99

    Available on demand.

    This book includes free shipping and is available on demand.

    Purchase Reward: One Month Free Subscription
    By completing any purchase on InformIT, you become eligible for an unlimited access one-month subscription to Safari Books Online.

    Get access to thousands of books and training videos about technology, professional development and digital media from more than 40 leading publishers, including Addison-Wesley, Prentice Hall, Cisco Press, IBM Press, O'Reilly Media, Wrox, Apress, and many more. If you continue your subscription after your 30-day trial, you can receive 30% off a monthly subscription to the Safari Library for up to 12 months. That's a total savings of $199.