Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Pair Programming Illuminated - Book Notes by Mind Map: Pair Programming Illuminated - Book
0.0 stars - reviews range from 0 to 5

Pair Programming Illuminated - Book Notes



Pair Programming, a style of programming in which two programmers work side by side at one computer, continually collaborating on the same design, algorithm, code or test

Driver, One of the pair typing at the computer or writing down a design

Navigator, Other partner which has many jobs, observe the work of the driver looking for defects, tactical - syntax, typos, calling wrong method etc, strategic - headed down the wrong path, implementation won't accomplish goal, Strategic thinker

Programming, design, development, debugging, testing etc

Why Pair?

Quality, pairs produce code with fewer defects

Time, pairs produce higher quality code in about half the time as individuals

Morale, pair programmers are happier programmers, helps job retention

Trust & Teamwork, pair programmers get to know their teammates much better, builds trust and improves teamwork

Knowledge Transfer, pair programmers know more about the overall system

Enhanced Learning, pairs continually learn by watching how their partners, approach a task, use language capabilities, use development tools, etc


1953 - Fred Brooks, author of The Mythical Man Month, "Bill Wright and I first tried pair programming when I was a grad student. We produced 1500 lines of defect-free code; it ran correctly first try"

1970's - Dick Gabriel, concieved Common Lisp and introduced patterns, reports pair programming in 1970s

1980's - Larry Constantine, author of more than 150 technical articles and 16 books, observed "Dynamic Duos" producing code faster and more bug-free than ever before., Concluded two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quaity

1995 - James Coplien of the Pasteur project at Bell Labs Research, Published the "Developing in Pairs" Organizational Pattern

2000 - Kent Beck, developed Extreme Programming (XP) methodolgy, Largest known group of pair programmers following XP

7 Myths of Pair Programming

It will double the workload with two doing the work one can do

reality - proved by a 16 week study at University of Utah, Get two people programming in pairs and they'll work more than twice as fast as one could have, majority of buggy production code comes from individually written code

I'll never get to work alone. I Couldn't stand that!

reality - based off of different surveys, ~30% spent working alone, ~50% spent pairing, ~20% spent working with more than 2

It will work well only with the right partner

reality, works well with most (though not all), usually those with excess ego and/or a 'my way or the highway' attitude is the exception

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

reality, two experts solving complex problems will come with a great solution, always better than what they would have come up with individually, two experienced programmers will fill many of each other's knowledge gaps, Everyone has gaps

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

reality, pairing is about better quality code and better solutions for the project and benefits the team overall, so desired personal success transitions to desired team success., individual success means nothing without team success (sports analogy), Need to put effort into peer evaluations, valuable feedback to management and peers

the navigator finds only syntax mistakes. Compilers can do that better than humans can.

reality, Navigator is doing more than syntax checks, Navigator is holding the roadmap and is caught up with staying between the lines on a winding road, Overall design is constantly being assessed and re-considered by navigator while driver implements the latest agreed on idea, Also help brainstorm - brainstorming concludes good designs much faster than individual considerations

Only time I ever get any real work done is when I'm alone.

reality, This idea comes from a desire to be in the 'flow' or the zone, the zone is a mythical desired state that is actually not optimal, see the Clean Coder notes, summary: zone == more code, but more code != better / less buggy / reliable / working code, Losing context or flow can happen with a 15 second interruption, a partner can help you get back into flow as they can continue to focus on the problem and bring you back in context very quickly, this context can take 15-30min to get back into individually (proven from Pragmatic Thinking and Learning - see notes ), A pair will get interrupted less than someone working individually at their desk

7 Synergistic Behaviours of Pair Programming

Pair Pressure

pair programmers put a positive form of pressure on each other., Programmers admit to working harder and smarter on programs because they do not want to let their partner down, Improved adherence to procedures and team standards

Pair Negotiation

stemming from 'distributed cognition,' two pair programmers arrive at the best solution together, each brings his/her own set of skills, abilities and outlook, both share the same goal for completing the task, jointly approach a problem each with a suggested alternative for attacking it, must 'negotiate' how to approach the problem jointly, evaluate more alternatives than either one would have considered alone, efficiently determines which is the best plan of attack, 'high five' eachother for being so smart and kicking butt on the task

Pair Courage

tremendous courage builder, giving us confidence to do things we might be afraid to do alone or simply might avoid and never do, Teacher analogy, Teacher asks all students to do a task and ask their answers at the end, only a few will respond, Teacher asks all students to work with a pair, nearly every pair will respond at the end, they are much more confidant in their answer

Strength in numbers!

Courage to admit when we don't know something, individually we would muddle through problems on our own embarrassed to ask others questions, in a pair we are much more likely to ask for help, Study shows 42% of developers are inclined to work on problems alone, the more experience a developer has the more likely he or she is to ask for help

Pair Reviews

4 eyes are better than 2

Studies show peer reviews find defects earlier and the earlier a defect is found the cheaper it is to fix, pairing gives you minute by minute peer review, best way to find all bugs as early as possible

Pair Debugging

It is a common and effective practice to explain a problem to an inanimate object like a teddy bear or a duck and in explaining we come to conclude our problems, amplify this when talking to another person. The back and fourth with a human can lead to solving hard problems quickly

Pair Learning

Knowledge is constantly being passed between partners, tool usage tips to programming language rules to design and programming idioms

Pair Trust

Pairing allows teammates to open up to each other's knowledge and experiences and to see tha tthe end result is far better than anything they could have developed on their own

Overcoming Management Resistance

"I have to pay two programmers to do the job 1 could do

Wrong, The pair will get tasks done faster and with considerable less bugs, 1 bug equates an unknown amount of future effort that is hard to estimate but is agreed it's always better to catch a bug earlier

What's In It For Me Goals

I want to complete my project on time with high-quality code, 1996 Hill Air Force Base Report, Study where projects were to be done in two-person teams where EVERYTHING was done as a pair, pairs produced 175 lines per person per month (lppm), individuals produced 77 lppm, error rate of was three orders of magnitude lower than the organization's norm when pairing, 1998 Temple University Professor Nosek Reported a study of 15 full time experience programmers, working for 45 minutes on challenging problems, 5 individuals, 10 as pairs (5 pairs), All the teams outperformed individuals, enjoyed the problem solving process more and had greater confidence in their solutions., pairs spent 60% more time on the task, however they were able to complete task in less 'wall-clock' time, 1999 Study by authors- University of Utah - 28 students in the Senior Software Engineering course, Even mix of experienced students, individuals and pairs with the same assignments (pairs having extra work outside of the study to keep fair workload), Pairs passed on average15% more of the automated postdevelopment test cases than the individuals, Individuals were intermittently late or failed to hand in a program, all pairs were always on time and never missed one, Programs were consistently more than 20% shorter than the individuals, Good sign of better design and lower projected maintenance costs, After gelling, pairs completed programs in the same time as individuals, on average it is believed to be 15% more time for pairs to 'solve' a problem as an individual, pairs actually 'solve' the problem while individuals have higher defects rate, poorer design, and a much higher maintenance cost, Industry data reports that between 33 and 88 hours are spent on each defect found in the field, When each defect saved during code development can save defect correction time of between .5 and 88 hours pair programming quickly becomes the cost-saving and time-saving alternative, Time to market is often half the time with pair programming

I want to reduce my risk of losing a key person, Multiple people are familiar with nearly every part of a system leaving no key persons, Truck number is 2+ depending on frequency of pair rotation

I want my employees to be happy, Happier employees stay in their jobs longer, Turnover is costly, Based on 7 independent surveys of self-selected pair programmers, over 90% of pair programmers agreed that they enjoyed their jobs more when pair programming, 96% indicated that pair programming made them more confident

I want to reduce the amount of time it takes to train a new person, training costs are reduced which helps me manage my budget, New people can actually contribute to projects much earlier, Pairing is training on actual tasks while traditional training does not contribute toward the completion of the project, teaching by doing and not showing which has been proven to be more effective

I want my teams to work well together and to communicate more effectively and efficiently with each other, My team works together better because they know each other and like each other, makes happier employees and reduces information islands, Pairing encourages interteam communications, without pairing often individuals would show up put their headphones on, eat alone and go home, Over time teams get closer, eat together, often have personal friendships outside of work, Rapport and trust builds

Gaining Support & Acceptance from Peers

Cites Introducing Patterns into Organizations (2002)

Evangelist, Gradually introduce casual, noninvasive use of the practice with your peers, "Test the Waters", Identify people that seem especially interested in new ideas - innovators, do your homework before enlisting their support, "Just Do It", Don't label it as "Pair Programming" - this makes people anxious, Don't be too concerned about following the driver/navigator model, Grow the pairs to other parts of the team forming the "Early Majority", This can lead to a "Grass Roots" effort

Local Leader, After you have an Early Majority talk to your management and get him/her to be a local leader, Track statistics, # of bugs before and after, first hand experience and discussion of productivity of the team, test results that show quality is improving

Brown Bag, lunch or department meeting, increase involvement and information about pair programming

Transitioning to Pair Programming by Choice

Adopted more when developers

have increased choice in when to use that innovation

have decreased process control in how to use that innovation, Can't be told how exactly to do it, Can't be wild wild west, teams need some level of consistent organizational standards and procedures

their manager encouraged them to use the innovative technique, discourage "if you want to pair, go ahead and pair - I don't care" attitude

the innovation increases the predictability of their work, pairing results from University of Utah performed more consistently and predictably than individuals

manager introduction

Be the Local Leader and also the Evangelist

Ask a Respected Techie to read about pair programming, Let him/her try it, Don't rush this process, It is important for this person to genuinely be convinced of the technique through experience, If they are not, ask them to not publicly criticize and pick another Respected Techie, Encourage the Respected Techie to gain the support of other programmers, ask this group to organize a Pair Programming Tutorial

Organize an educational session for a larger organization, Run by the senior developers without management present, Should be prepared with a "Personal Touch", specific way that pair programming can personally help each person get his/her job done better, my examples, do away with the useless peer review comments, someone can actually help you, work gets done while you are in a meeting or someone interrupts you at your desk, bring up the negative things you have heard or anticipate audience bringing up, better management of the resistance and ensures all concerns are heard

The Desired Accomplishments, Programmers who are interested in trying should sign up, team should develop an informal plan for who should try pairing with whom, Initial trial of technique should feel low risk for all invovled, Put in place a system of feeding back concerns and successes of these trials, can be as informal as stopping by senior programmers desk periodically, can be as formal as tracking progress / defects, Team should then discuss what would convince them that pair programming is or is not a valid technique, should decide what data they want to collect and how long it will take for them to decide on the validity of the technique, Team should discuss organizational guidelines for use of pairing, example, pairing takes place between 9-11 and 1-3, no meetings should be held during this time, interruptions of any kind should be avoided

Involve Everyone, including skeptics, maybe pair an early adopter with a skeptic

Advice for Programmers

suspend disbelief and don't make threats, you never know what you might learn and too quick a reaction will make it all that much harder, form opinions after trying it for a couple of weeks

pretend it will work to give it a fair shot

Problem, Problems


Becomes harder for developers to program alone, If you're alone, find another partner, or help be the second with someone else

They feel less confidant and can grow dependent of the partner, Always review what was done alone, with the pair, this will help keep things moving but still have confidant and allow for review and bug catching


Can be more difficult to schedule, Can be easy if always pairing with the same person

A lot of benefits to rotating pairs, so it needs to be managed, my ideas, Scrum bullpen environment, Meetings are often unnecessary - skip and continue to do work

The Ever-Popular Expert

Continuation of the scheduling problem

NOT a problem with scrum

GUI / Database / Kernal experts, Best to let them have time to work their critical tasks alone, potentially set up office hours, ( again, not a problem when using scrum )


People come in to work at different times and have different schedules

Balance between the needs of the project and the needs of the employees, core pair programming hours

Remote workers - distributed pair programming, not as effective but it can be a valid option

Noise and Facility Considerations

requires a commitment from the organization in terms of facility changes.

more appropriate desk setups / cubicle space


You can still work alone for a truly creative requirement and then come back together with a pair to discuss conclusions, Be open to revising your brainstormed-in-isolation solution, Most certainly, your partner can think of something you didn't think of when you were alone


Strategies for resolving conflicts, each of you go off alone for a specified period of time to cool off and investigate what you feel so strongly about, Take a walk around the building -- together!


Sometimes a pair can feel they can do no wrong when working together


Highly effective teams can sometimes feel a need to complete a task during a session., Sometimes you need to not rush a solution and resolve it next session

Skill Imbalances

Pair new team members with mentoring types to keep them feeling welcome and limit frustrations, Mentor needs to give up control and allow the less skilled to drive most of the time

Simply Not for All

Might not work for someone, too introverted, soft spoken, or lacks confidence, Might grow into it with pairing of a great mentor or another very similar introvert, too self centred, egotistical or feels threatened

Workplace Layout

Basic Needs

sit comfortably side by side

both can completely view the monitors

Suggested Workplace Enhancements

Cave and Commons, Outer cubbies for devs to call home, may or may not have computers, a private space to decorate and take phone calls, primary focus is on pairing stations at tables in the center for the team to work together optimally

1 Computer, 2 Displays, 2 Keyboards, 2 Mice

Interpair Communications

Pairs need to be able to hear others pairs on the team

There is a lot of benefits to overhearing other conversations to help each other out even when not directly communicating

Development Environment

Ideally there is a standardized enviornment

The team needs to agree to program in a different environment for at least half the time for the next 'n' weeks, 'n' doens't have to be too high before they decide they can converge on a single enviornment

Pair Rotation: Communication, Knowledge Management, and Training

Pair Rotation

Usually happens very casually without any formal schedule, Teams learn to choose the right partner for the right situation

Easiest to stomach and accomplish with small tasks (< week)

Partner Assignment, Daily Scrum a good time to identify when we can help each other and self identify to pair with someone, Just say yes strategy, When someone takes a task they ask someone to pair with them and said someone can't say no


Pairing can reduce training time by a factor of two compared to not pairing

Split the team into 'Progress' team and 'Training' team, Training team is made of mentors and new team members, As team members pair and gain enough experience they transition to the progress team

Other Issues to Consider

Performance Appraisals

Companies often focus on individual performance

Switch to utilize peer evaluations, After all, who knows better?, Ask the employee for 3 names of who to have peer evaluate, and 3 names of who should NOT peer evaluate to give a guideline on personal conflicts

Team Size

keep it small (scrum team size applies)

Try to have even number teams =)

Quality Assurance

Pair Programming is another QA checkpoint which will reduce bugs and improve quality heavily

'Formal Testing' time is often reduced due to all the benefits

Peer reviews also go smoother or become obsolete at times

Functional and System Testing

Encourage testing be a pairing activity as well

Tips and Tricks

Give the driver a few nanoseconds to find and correct his or her own mistakes

Same for navigating menus etc

If your partner is getting bored pass them the keyboard

If both of you are tired, get up and walk around or take a break

If your partner is getting tired or frustrated, grab the keyboard

Come to an understanding on how pairing will work with a new pair

Negotiate on what each person likes to do and how. What each does well etc

Takes < 5 min

Handling Conflict

Navigator record (on cards) contentious issues that are bothering the driver., Review every half hour., This allows progress to continue but concerns to be addressed before it becomes too late

Separate for a period of time ~ 10 min, investigate on their own, take a walk, get back together to discuss their investigation

Let the navigator drive for 5 minutes, If driver agrees, driver can finish it out, if not he can roll back, Sometimes just trying can make both sides see the good and bad and lead to an agreement

Use a coding standard

Eliminates partner disagreement due to style

Use test driven development

Helps facilitate switching between driver and navigator

Practice active listening

Acknowledge, restate, and summarize ideas

Talk a lot

Talk about what you're diong

Explain techniques for using the development enviornment

If your partner is not listening at all, get up and walk away

Just ask!

If you don't understand what your partner is doing, stop and ask, Still don't get it? Ask again!

It can be tough to learn to talk while driving, help each other out. We aren't keeping secrets we just forget how to share them

Take enough showers, eat lots of breath mints

Pair Programming Partner Picking Principles

Partner Dynamics

Definitions, Average Programmer, Lots of experience but just average, Little experience becoming an expert, Novice Proogrammer, Doesn't necessarily mean new dev but maybe just new to the team

Expert-Average Pairing, Intent, Accomplish average job, Raising the skill level of one pgorammer, Characteristics of Success, Not Average 1 programmer, but an Average 2 programmer, Expert does some mentoring, Slow down sometimes and explain the "why", Teach how to pair first, then teach how to program, Challenges, Average programmer really is average, not interested in expanding & learning new things, Average programmer does not interact enough w/ the expert, Average programmer doesn't seem to "get it"

Expert-Novice Pairing, Intent, Get easy jobs done well while training a novice programmer, Characteristics of Success, Novice learning by watching the expert, Novice helps the expert do a better job, "You don't really know it until you have to teach it", Similar to talking to the teddy bear but this bear talks back, Challenges, Teacher like qualities in expert required, Patience, ability to articulate clearly, compassion, patience, Comfortable environment that is nonthreatening, Expert not open to listening to advice from apprentice

Novice-Novice Pairing, Intent, Produce production code in a relatively noncomplex area of the project giving valuable experience to both programmers, Characteristics of Success, Helping each other learn, Together are willing to get help and move forward, Individually they might not ask for help so soon, Coach, instructor or mentor available to answer questions and help guide the pair, Works best in a class/teaching enviornment, Challenges, Easy for the pair to go down the wrong path, focus on non importatn tasks or trviailities

Extrovert-Extrovert Pairing, Intent, After long, thoughtful, constructive discussions, an excellent creative solution is created, Characteristics of Success, Pairing is all about communication, typically extroverts are the best communicators, Will often openly question decisions, will jointly arrive at the best solution, Challenges, Loud and full of laughter, can also spend lots of time talking, discussing and arguing, need to stay productive otherwise pairing will fail, Book points out this is simply just non productive time but I believe this is also a huge bonding and living time. This may mean some time is charged not on work, but lets not kid ourselves, everyone is having conversations, at least in a pair you have the easier opportunity to get back to work once a conversation is over.

Extrovert-Introvert Pairing, Intent, Allow each partner to draw on his or her strengths and to improve upon his or her weakness, Characteristics of Success, Pairing still works in these groups, Introverts need to learn to speak up when it's important, Extrovert needs to learn to shut up, Extrovert must consciously work not to talk all the time and to draw valuable information from their partner, ask questions to their partner, extroverts will intentioinally make mistakes to see if the introvert will speak up and use that to open them up, Introverts must speak up when there is a problem or if they disagree or don't understand, Have to learn to express themselves and to let their talents show, Challenges, Each partner must give up a little from their personality

Introvert-Introvert Pairing, Intent, A silent intensity leads to rock-solid solutions, Characteristics of Success, Maintain a decent level of interaction, not a lot of verbal communication but other means of communication, Challenges, Introverts can be very poor communicators, If there is no communication there is no pair programming, keep people pairing and let them get to know each other., Managers or others should interject into the pair and ask questions to ensure they are communicating with each other, Introverts like to work locked away in a cave, they will strongly resist pairing, Take it slow, Developing out of office relationships can help gain comfort in pairing and opening up

Nonissue Dynamicis

Gender Nonissue, Issue, Gender is not an issue, What This is About, Partner Dynamics still apply but gender makes no difference to them, Communication is the key and men and women communicate differently, Men attempt to convey information, speaking about things, Women communicate to receive information or to improve relationships and speak mostly about people, If There are Problelms, Usually is Gender Disrespect, This is a problem regardless of pairing, not specific to pairing and should be addressed, shouldn't just skip pairing

Culture Nonissue, Issue, Having pairs w/ different cultural backgrounds is wonderful for building trust and communication, As long as there is communication, the pair can succeed, What This is About, Culture doesn't matter as long as they communicate, Verbal and nonverbal, Actually pair programming w/ culturally diverse team can help everyone understand each other and gain trust, This is usually hard to achieve as we naturally segregate with those we feel comfortable / similar to us, If There are Problems, Cultural bigotry can exist in either partner, Pairing can bring this to the surface quickly, This is going to happen regardless, should be addressed quickly

Real Problems

Professional Driver Problem, Root Cause, Desire for power, lack of confidence in partner, navigators lack of confidence in himself, General Form, driver will not give up control of keyboard, Leads to less confidence in navigator driving and makes the problem worse, This is okay if navigator has physical problems driving (super mega slow, broken arm etc), Driver unwilling to listen very much to navigator, Navigator feels disjointed, out of the loop, unimportant, Refactored Solution, Train driver on the benefits of pairing, Maybe have driver watch other pairs to understand how the team should work together, Professional navigators must force themselves to take control

My Partner is a Total Loser and Other Excess Ego Problems, Root Cause, Attitude problem, usually nothing to do w/ the partner, the person just feels that he or she is better than anyone else, General Form, Partners can't stand to pair with the person, Smoke, fire, and yelling are good indicators, Intimidates his partner, Cohesion of the entire team becomes at risk, Refactored Solution, Best solution: Fire this person, Get known good partners to pair with them and show they can be valuable, Counsel the person and get them to acknowledge the problem and attempt to keep the ego in check

My Partner is SO Smart and Other Too Little Ego Problems, Root Cause, someone simply has zero confidence in themselves and feels inadequate in accomplishing even basic tasks, General Form, readily apparent, Have techniques to hide it - quiet, return questions instead of answering, "flip the bozo bit", Refactored Solution, Let those who lack confidence drive, Pair them with someone with good people skills, give genuine compliments, ask for their opinions. try to draw them out to be involved., lighten the mood with comedy / jokes

Moving Ahead and Going Beyond


three very experienced, mature and responsible

complex problem that justifies 3 brains

Keyboard, white board, and thinking out loud

Multidisciplinary Pairs

UI specialist with developer

tester and developer

Customer and developer

Projection Screen

No longer constrained by the desk

Supportive of triplet programming

Distributed Pair Programming

Don't perform as well as face to face pairing

Needs periodic face to face pairing to get to know each other and keep up with how to work together

Requires more verbal communication than ever

Seeing each other (web cams) is important for communication

Seven Habits of Effective Pair Programmers

Take Breaks

Check emails, return phone calls, etc

Practice Humility

It's okay to not know something, admit it and start helping the team as best you can

We all make mistakes, let others help you fix them before they go to prod.

Be Confident / Be Receptive

No judging, no competing with each other.

Work Together


15 sec without talking is long, 30 sec is an eternity

Programmers are stereotyped as quiet, but really they like to talk about what they are interested in, like programming

This is not a force of extroverts, this is excelling at what they do and showing colleagues and being shown by colleagues


Listen to details and try to stop assuming

Be a Team Player

Your partners work == your work

Use the word "we" a lot

If you don't understand something, ask, you are responsible for all of this work too

Hone the Balance between Compromise and Standing Firm