Pair Programming Illuminated - Book Notes

Get Started. It's Free
or sign up with your email address
Pair Programming Illuminated - Book Notes by Mind Map: Pair Programming Illuminated - Book Notes

1. Transitioning to Pair Programming by Choice

1.1. Adopted more when developers

1.1.1. have increased choice in when to use that innovation

1.1.2. 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

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

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

1.2. manager introduction

1.2.1. Be the Local Leader and also the Evangelist

1.2.2. 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

1.2.3. Organize an educational session for a larger organization Run by the senior developers without management present Should be prepared with a "Personal Touch" bring up the negative things you have heard or anticipate audience bringing up

1.2.4. 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

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

1.3. Advice for Programmers

1.3.1. 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

1.3.2. pretend it will work to give it a fair shot

2. Problem, Problems

2.1. Dependency

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

2.1.2. 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

2.2. Scheduling

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

2.2.2. 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

2.3. The Ever-Popular Expert

2.3.1. Continuation of the scheduling problem

2.3.2. NOT a problem with scrum

2.3.3. 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 )

2.4. Colocation

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

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

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

2.5. Noise and Facility Considerations

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

2.5.2. more appropriate desk setups / cubicle space

2.6. Concentration

2.6.1. 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

2.7. Disagreements

2.7.1. 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!

2.8. Overconfidence

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

2.9. Rushing

2.9.1. 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

2.10. Skill Imbalances

2.10.1. 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

2.11. Simply Not for All

2.11.1. 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

3. Workplace Layout

3.1. Basic Needs

3.1.1. sit comfortably side by side

3.1.2. both can completely view the monitors

3.2. Suggested Workplace Enhancements

3.2.1. 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

3.2.2. 1 Computer, 2 Displays, 2 Keyboards, 2 Mice

3.3. Interpair Communications

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

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

3.4. Development Environment

3.4.1. Ideally there is a standardized enviornment

3.4.2. 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

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

4.1. Pair Rotation

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

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

4.1.3. 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

4.2. Training

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

4.2.2. 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

5. Other Issues to Consider

5.1. Performance Appraisals

5.1.1. Companies often focus on individual performance

5.1.2. 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

5.2. Team Size

5.2.1. keep it small (scrum team size applies)

5.2.2. Try to have even number teams =)

5.3. Quality Assurance

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

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

5.3.3. Peer reviews also go smoother or become obsolete at times

5.4. Functional and System Testing

5.4.1. Encourage testing be a pairing activity as well

6. Tips and Tricks

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

6.1.1. Same for navigating menus etc

6.2. If your partner is getting bored pass them the keyboard

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

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

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

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

6.4.2. Takes < 5 min

6.5. Handling Conflict

6.5.1. 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

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

6.5.3. 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

6.6. Use a coding standard

6.6.1. Eliminates partner disagreement due to style

6.7. Use test driven development

6.7.1. Helps facilitate switching between driver and navigator

6.8. Practice active listening

6.8.1. Acknowledge, restate, and summarize ideas

6.9. Talk a lot

6.9.1. Talk about what you're diong

6.9.2. Explain techniques for using the development enviornment

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

6.11. Just ask!

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

6.11.2. 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

6.12. Take enough showers, eat lots of breath mints

7. Pair Programming Partner Picking Principles

7.1. Partner Dynamics

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

7.1.2. 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 Challenges Average programmer really is average Average programmer does not interact enough w/ the expert Average programmer doesn't seem to "get it"

7.1.3. 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 Challenges Teacher like qualities in expert required Comfortable environment that is nonthreatening Expert not open to listening to advice from apprentice

7.1.4. 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 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

7.1.5. 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 Challenges Loud and full of laughter

7.1.6. 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 Extrovert must consciously work not to talk all the time and to draw valuable information from their partner Introverts must speak up when there is a problem or if they disagree or don't understand Challenges Each partner must give up a little from their personality

7.1.7. 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 Introverts like to work locked away in a cave, they will strongly resist pairing

7.2. Nonissue Dynamicis

7.2.1. 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 If There are Problelms Usually is Gender Disrespect

7.2.2. Culture Nonissue Issue Having pairs w/ different cultural backgrounds is wonderful for building trust and communication What This is About Culture doesn't matter as long as they communicate Actually pair programming w/ culturally diverse team can help everyone understand each other and gain trust If There are Problems Cultural bigotry can exist in either partner

7.3. Real Problems

7.3.1. 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 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 Professional navigators must force themselves to take control

7.3.2. 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 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

7.3.3. 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

8. Introduction

8.1. Definitions

8.1.1. 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

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

8.1.3. Navigator Other partner which has many jobs observe the work of the driver looking for defects Strategic thinker

8.1.4. Programming design, development, debugging, testing etc

8.2. Why Pair?

8.2.1. Quality pairs produce code with fewer defects

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

8.2.3. Morale pair programmers are happier programmers helps job retention

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

8.2.5. Knowledge Transfer pair programmers know more about the overall system

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

8.3. History

8.3.1. 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"

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

8.3.3. 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

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

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

9. 7 Myths of Pair Programming

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

9.1.1. 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

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

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

9.3. It will work well only with the right partner

9.3.1. 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

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

9.4.1. 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

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

9.5.1. 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

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

9.6.1. 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

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

9.7.1. 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 Losing context or flow can happen with a 15 second interruption A pair will get interrupted less than someone working individually at their desk

10. 7 Synergistic Behaviours of Pair Programming

10.1. Pair Pressure

10.1.1. 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

10.2. Pair Negotiation

10.2.1. 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

10.2.2. Improved adherence to procedures and team standards

10.3. Pair Courage

10.3.1. 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

10.3.2. Strength in numbers!

10.3.3. 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

10.4. Pair Reviews

10.4.1. 4 eyes are better than 2

10.4.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

10.5. Pair Debugging

10.5.1. 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

10.6. Pair Learning

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

10.7. Pair Trust

10.7.1. 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

11. Overcoming Management Resistance

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

11.1.1. 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

11.2. What's In It For Me Goals

11.2.1. 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 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) 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) 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

11.2.2. 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

11.2.3. 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

11.2.4. 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

11.2.5. 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

12. Gaining Support & Acceptance from Peers

12.1. Cites Introducing Patterns into Organizations (2002)

12.1.1. 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 "Just Do It" Don't label it as "Pair Programming" - this makes people anxious Grow the pairs to other parts of the team forming the "Early Majority" This can lead to a "Grass Roots" effort

12.1.2. 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

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

13. Moving Ahead and Going Beyond

13.1. Triplets

13.1.1. three very experienced, mature and responsible

13.1.2. complex problem that justifies 3 brains

13.1.3. Keyboard, white board, and thinking out loud

13.2. Multidisciplinary Pairs

13.2.1. UI specialist with developer

13.2.2. tester and developer

13.2.3. Customer and developer

13.3. Projection Screen

13.3.1. No longer constrained by the desk

13.3.2. Supportive of triplet programming

13.4. Distributed Pair Programming

13.4.1. Don't perform as well as face to face pairing

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

13.4.3. Requires more verbal communication than ever

13.4.4. Seeing each other (web cams) is important for communication

14. Seven Habits of Effective Pair Programmers

14.1. Take Breaks

14.1.1. Check emails, return phone calls, etc

14.2. Practice Humility

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

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

14.3. Be Confident / Be Receptive

14.3.1. No judging, no competing with each other.

14.3.2. Work Together

14.4. Communicate

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

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

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

14.5. Listen

14.5.1. Listen to details and try to stop assuming

14.6. Be a Team Player

14.6.1. Your partners work == your work

14.6.2. Use the word "we" a lot

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

14.7. Hone the Balance between Compromise and Standing Firm