Register your product to gain access to bonus material or receive a coupon.
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.
Overcoming Management Resistance to Pair Programming
Click below for Sample Chapter(s) related to this title:
Sample Chapter
4
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.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.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.
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:
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.
Click below to download the Index file related to this title:
Index