Effective Pair Programming

Laten we beginnen. Het is Gratis
of registreren met je e-mailadres
Effective Pair Programming Door Mind Map: Effective Pair Programming

1. What is Pair Programming?

1.1. Definition

1.1.1. Style of programming

1.1.2. two programmers

1.1.2.1. working side by side

1.1.3. 1 computer

1.1.3.1. 1/2 keyboards

1.1.3.2. 1/2 mice

1.1.4. Continually collaborate

1.1.4.1. on

1.1.4.1.1. design

1.1.4.1.2. coding

1.1.4.1.3. testing

1.1.4.1.4. etc

1.1.4.2. Work together

1.1.4.2.1. High Communication

1.1.4.2.2. High Focus

1.1.4.2.3. Double checking work

1.1.4.2.4. Planning the next step

1.1.4.2.5. Solving the Problem Together

1.2. Roles

1.2.1. Driver

1.2.1.1. The one typing at the computer

1.2.1.1.1. Implementing the current test / solution

1.2.1.1.2. Focused heavily on the syntax of the for loop etc

1.2.1.2. Writing down a design

1.2.2. Navigator

1.2.2.1. Observes the work of driver

1.2.2.1.1. looking for defects

1.2.2.1.2. strategic

1.2.2.2. Planning the next step

1.2.2.2.1. Ensuring the current implementation is going to work with the next design step

1.2.2.2.2. Designing the next test to make pass

1.2.2.2.3. Finding the best implementation for the next step

1.2.2.2.4. Considering the best way to refactor current solution

1.3. How it Works

1.3.1. Lots of Communication

1.3.1.1. Lots of Questions!

1.3.1.1.1. Why are you doing it that way?

1.3.1.1.2. What's the next step?

1.3.1.1.3. How do you think we should do this?

1.3.1.1.4. Should we test it this way?

1.3.1.1.5. What if we try this?

1.3.1.2. Lots of Pointing

1.3.1.2.1. Finger (Don't touch the screen)

1.3.1.2.2. Using the Mouse

1.3.1.3. Nonverbal

1.3.1.3.1. Grunting

1.3.1.3.2. Laughing

1.3.1.3.3. Crossed Arms

1.3.1.3.4. Eye Rolling

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

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

1.3.1.4.2. Takes < 5 min

1.3.1.5. Practice active listening

1.3.1.5.1. Acknowledge, restate and summarize ideas

1.3.2. Constantly Switching Roles

1.3.2.1. Ping Pong Programming

1.3.2.1.1. Write the test, switch roles

1.3.2.1.2. write both the test and implementation, switch roles

1.3.2.2. Small Tasks

1.3.2.2.1. Helps identifying switch points

2. Benefits of Pair Programming

2.1. Software Quality

2.1.1. Pair Negotiaion

2.1.1.1. pair programmers arrive at the best solution together

2.1.1.1.1. each brings their own set of skills, abilities and outlook

2.1.1.1.2. both share the same goal for completing the task

2.1.1.1.3. must 'negotiate' how to approach the problem jointly

2.1.1.1.4. Pairs produce code with fewer defects

2.1.1.2. Conclude that the end result is far better than anything they could have developed on their own

2.1.2. Pair Reviews

2.1.2.1. 4 eyes are better than 2

2.1.2.2. Peer reviews are a heavy focus because they have been proven to find defects earlier

2.1.2.2.1. The earlier a defect is found the cheaper it is to fix

2.1.2.2.2. Pairing gives minute by minute peer review, the best way to find 'all' bugs as early as possible

2.1.2.3. work done individually is often reassessed early and the better solution is implemented

2.1.2.3.1. It's not too late to do what's right

2.1.2.4. These are actual peer reviews vs many complaints of peer reviews not adding real value

2.1.2.4.1. Not Just Feng Shui

2.2. Saved Time

2.2.1. Gelling pairs produce higher quality code in about half the time as individuals

2.2.2. Pair Pressure

2.2.2.1. pair programmers put a positive form of pressure on each other

2.2.2.1.1. Programmers admit to working harder and smarter because they do not want to let their partner down

2.2.2.1.2. Improved adherence to procedures and team standards

2.2.3. Pair Courage

2.2.3.1. Strength in numbers!

2.2.3.2. tremendous courage builder giving us confidence to do things we might be afraid to do alone

2.2.3.2.1. Teaching Analogy

2.2.3.3. Courage to admit when we don't know something

2.2.3.3.1. individually we may muddle through problems on our own, embarrassed to ask others questions

2.2.3.3.2. Study shows 42% of developers are inclined to work on problems alone

2.2.4. Pair Debugging

2.2.4.1. Most common use of pairing

2.2.4.2. Rubber Duck Debugging It is a common and effective practice to explain a problem to an inanimate object like a teddy bear or a rubber duck

2.2.4.2.1. The act of explaining the problems will often lead you to a solution

2.2.4.2.2. Constant communication will increase this technique

2.2.4.2.3. Also this bear will talk back

2.2.5. Interruptions

2.2.5.1. Person out (sick, meetings, training...)

2.2.5.1.1. Doesn't halt an entire task/story

2.2.5.1.2. Pair can catch up when they are back

2.2.5.2. Drive Bys

2.2.5.2.1. People tend to interrupt less if you are working with someone else

2.2.5.2.2. If you are interrupted

2.3. Knowledge Sharing

2.3.1. Knowledge is constantly being passed between partners

2.3.1.1. tool usages tips

2.3.1.2. programming language rules

2.3.1.3. design and programming idioms

2.3.1.4. how to approach problems

2.3.1.5. Pair programmers know more about the overall baseline

2.3.2. Training New Team Members

2.3.2.1. Costs are reduced in training as training time can reduce by a factor of two

2.3.2.2. New people can actually contribute to projects quickly

2.3.2.3. Teaching by doing, not showing, has been proven to be more effective

2.4. Strengthens Teams

2.4.1. Pair Trust

2.4.1.1. Pairing allows team mates to open up to each other's knowledge and experiences

2.4.1.1.1. get to know their team-mates much better

2.4.1.1.2. builds trust and improves teamwork

2.4.1.1.3. allows team to share more freely

2.4.2. Morale

2.4.2.1. Pair programmers are happier programmers

2.4.2.1.1. helps job retention

2.4.2.2. Constant Team Building

3. Nick's take on when to use Pair Programming

3.1. This is Nick's idea. Management is not telling you to use Pair Programming.... But I am

3.2. Scrum

3.2.1. Ken Schwaber - Scrum Et Al

3.2.2. When you NEED something done

3.2.2.1. You setup a team

3.2.2.2. Give them the resources to do their job

3.2.2.3. Let them decide how best to do their job

3.2.2.4. You leave them alone and check status every few weeks

3.2.3. Don't do this when you HAVE to get stuff done

3.2.3.1. Do it ALL the time

3.2.3.1.1. This is called Scrum

3.3. Pair Programming

3.3.1. When you really NEED something done

3.3.1.1. You work with someone else

3.3.1.2. Together you debug/troubleshoot code

3.3.1.3. Together you decide the best solution

3.3.1.4. Together you implement and test

3.3.2. Don't do this when you HAVE to get stuff done

3.3.2.1. Do it ALL the time

3.3.2.1.1. This is called Pair Programming

4. Presenters

4.1. Nicholas Tuck

4.1.1. Pair Programming for 4 years

4.1.2. AFWWEBS / MetServices Developer 4 Years

4.1.2.1. Team pairing full time for 2 years

4.2. Brandon McAllister

4.2.1. Pair Programming for 3 years

4.2.2. AFWWEBS / MetServices Developer 2 Years

4.3. AFWWEBS / Metservices Team pairing full time for 2 years

4.4. Sit by Andy Sedlacek, in front of Trent's office

5. Resources

5.1. Pair Programming Illuminated

5.1.1. Amazon Book

5.1.2. My Notes

5.1.3. SEMS owns 2 copies

5.2. C2 Pair Programming Wiki

5.2.1. Super awkward wiki

5.2.2. Lots of great pages, definitions, and ideas

6. Goals

6.1. Understand

6.1.1. WHAT Pair Programming is

6.1.2. Benefits of Pair Programming

6.1.3. Myths of Pair Programming

6.2. Learn some Techniques

7. Tips and Tricks

7.1. If your navigator is getting bored, pass them the keyboard

7.1.1. If you both are tired, get up and walk around

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

7.3. Handling Conflict

7.3.1. Navigator record contentious issues

7.3.1.1. Review every half hour

7.3.1.2. Allows progress

7.3.2. Separate for a period of time

7.3.2.1. ~ 10 min

7.3.2.2. Do separate investigation

7.3.2.3. Get back together and discuss

7.3.3. Let the navigator drive for 5 minutes

7.3.3.1. If driver agrees with the solution, driver can finish it out. Otherwise rollback

7.3.3.2. Sometimes just trying can make both sides see the good and bad and lead to an agreement

7.4. Environment

7.4.1. Sit comfortably side by side

7.4.1.1. Rotate sitting positions

7.4.1.2. Or stand

7.4.2. Both can completely view monitors

7.4.3. 2 mice, 2 keyboard

7.4.3.1. no more awkward mouse dance / accidental hand holding

7.4.4. Rearrange

7.5. Use test driven development

7.5.1. helps facilitate switching roles

7.6. Practice Humility

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

7.7. Take Breaks

7.7.1. check email, return phone calls, etc

7.8. COMMUNICATE

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

7.8.2. Programmer's are stereotyped as quiet, but really we love to talk about what we are interested in... like programming

7.8.2.1. This is not forcing introverts to be an extrovert, this is professionals excelling at what they do and showing colleagues their work

7.9. Be a Team Player

7.9.1. your partner's work == your work

7.9.2. Use the word "we" a lot

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

8. Myths of Pair Programming

8.1. The team productivity will be cut in half

8.1.1. reality

8.1.1.1. Get two people programming in pairs and they'll work more than twice as fast as one could have

8.1.1.2. Majority of buggy production code comes from individually written code

8.1.1.2.1. A bug can range in effort dramatically so reducing bugs earlier saves an indeterminate amount of time very quickly

8.1.1.3. Proved by a 16 week study at University of Utah

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

8.2.1. reality

8.2.1.1. Navigator is doing more than syntax checks

8.2.1.2. Navigator is holding the roadmap and is caught up with staying between the lines on a winding road

8.2.1.3. Overall design is constantly being assessed and re-considered by navigator while driver implements the latest agreed on idea

8.2.1.4. Also help brainstorm - brainstorming concludes good designs much faster than individual considerations

8.3. Pair Programming is good for training, but once you know what you're doing it is a waste of time

8.3.1. reality

8.3.1.1. Two experts solving complex problems will come up with a great solution, always better than what they would have come up with individually

8.3.1.2. Two experienced programmers will fill many of each other's knowledge gaps

8.3.1.2.1. everyone has gaps

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

8.4.1. reality

8.4.1.1. ~50% spent pairing

8.4.1.2. ~30% spent working alone

8.4.1.3. ~20% spent working with more than 2

8.5. It will work well only with the right partner

8.5.1. reality

8.5.1.1. Works well with most (though not all)

8.5.1.1.1. Usually those with excess ego and/or a 'my way or the highway' attitude is the exception

8.5.1.2. Managed approaches to the different dynamics of pairs are well described in the Pair Programming Illuminated book

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

8.6.1. reality

8.6.1.1. Pairing is about better quality code and better solutions for the projects and benefits the team overall

8.6.1.1.1. so desired personal success transitions to desired team success

8.6.1.1.2. individual success means nothing without team success

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

8.7.1. reality

8.7.1.1. Interruptions while working alone can make you lose context (all it takes is 15 seconds)

8.7.1.1.1. A partner can help you get back into flow

8.7.1.2. A pair is interrupted less than someone working individually

8.7.1.3. "real work"does != better / less buggy / reliable / working code

8.7.1.4. Mental blocks happen

8.7.1.4.1. pairing helps prevent and work through them

8.7.1.5. Surveys show 90% of those who pair enjoy programming more and feel more confident when pairing

9. Questions

9.1. Parking Lot