6. (all the other points are side-products)
producing
software
high quality
7. Test Driven Development
Behavior Driven Development
Acceptance Testing
Unit Testing
Continuous Integration
Continuous Delivery
Emergent Simple Design
Code Review
Design Patterns
Clean Code Principles
Coding Standards
SOLID Principles
Continuous Deployment
Enterprise Environments
Version Control Systems
PAIR PROGRAMMING
a practice in
development
8. P.J. Plauger, one of the implementors of C: "At each terminal were two
programmers! Of course, only one programmer was actually cutting code
at each keyboard, but the others were peering over their shoulders.”
1978-1988
1995
“Developing in Pairs” pattern in Jim Complien's book
"Pair Programming Illuminated", by Laurie Williams and Robert Kessler,
is the first book devoted exclusively
2002
PAIR PROGRAMMING
9. Core Practice in Extreme Programming
http://www.extremeprogramming.org/rules/pair.html
PAIR PROGRAMMING
15. Pairing does not amplify my productivity. Instead,
it erases all the bad habits I have that keep me from
being a superstar on my own.
h!p://www.sarahmei.com/blog/201%4/14/thoughts-on-two-months-of-pairing
21. MANY PEOPLE HATE IT
So that's why I don't like pair programming. My
weaknesses are exaggerated and my strengths are
vetoed. For me, pairing doesn't work. For plenty of
others, it very clearly does work. But not me. And
that's why I quit the best company I've ever
worked for: Pivotal Labs.
h!p://mwilden.blogspot.com.tr/2009/11/why-i-dont-like-pair-programming-and.html
22. Learn how to do
Have desire
Define coding standards
Have experienced people
Practice and be patient
Inspect and adapt
PRACTICE
PROGRAMMING
PAIR
TO MAKE
STEPS
YOURINDISPENSABLE
25. Besides, if people program solo,
they are more likely to make mistakes,
more likely to over design, and
more likely drop the other practices,
particularly under pressure.
XP Explained
26. Higher quality in code
Higher morale
Better collaboration
Shared knowledge
Quicker to market
Automatic code review
Useful for training people
Lower defect rates
Faster defect removal
Cannot force people
Tiring
Hard to setup common infra
Hard to keep focus
Clash of egos
Harder for introverts
No multiple committers
Easy to do anti-patterns
More effort on first & last sprint
BENEFITS
CAVEATS
28. Select you pair wisely1 Don't force people who don't like each other to pair
Two juniors might not be a good idea
29. Start with a reasonably well-
defined task before you sit down2
It's better if you do not need to investigate a lot
how to program or which technologies to use
30. Agree on one tiny goal at a time3 Define your checkpoints. Select minor goals.
32. Talk a lot!5
Does that look correct to you?
Do you think this is a valid test?
What’s next?
Trust me!
Do you have any better idea?
I suggest better names for variables and classes
I suggest to implement in smaller steps
I suggest possible inputs that we haven’t covered
Let me give you some details about this technology
Think out loud
37. Schedule the pairings if required
Pairing full time is not practical
25% for 3 days in a week
50% for 2 days in a week
Revisit how you pair after sprints
Talk on pairing schedules daily
10
39. Give breaks1 Pair programming is an exthausting practive. Never exceed 50 mins.
You can use pomodoro counters for 25 mins intervals.
40. Switch the keyboard
It's not a mentorship program, it is a development practice.
Give that f*ucking keyboard to your pair and switch the roles.
2
41. Write tests, no matter what
You can get the most out of pair programming if you write tests.
Try to write tests first and push yourself to do TDD.
3
42. Take your personal time
You need to read more, practice more, investigate more, learn more.
Take your time for working alone at least few hours a day.
4
43. Full day pairing is ok, but not
sustainable
You have to come to office at the same time, go to lunch together,
take breaks at the same time, leave the office at the same time.
5
44. Ask for used shortcuts, and learn
Learn all the tricks and shortcuts your pair uses. If you notice
your pair goes fast, stop him/her and ask the trick.
6
45. Do not worry about silly mistakes
Hey you know that. It is normal to do silly mistakes. Relax.
If your pair makes you stressed, let him/her know!
7
46. No one should be forced to pair
However if pair programming is a core practice in your company,
you might have to spend a lot of time with pairing.
8
47. Ask for your pair's opinion
Pairing is a matter of attitude. Do not always tell what to do.
Ask for suggestions and discuss together.
9
50. Do not fall into Anti-Pattern trap
Know the ways how you can screw up pairing and do your best
accordingly.
51. Superman
I am fast, give me keyboard
Absent-Mind Ed
I am too distracted
The Back-Seat Driver
Tons of non-trivial comments
The King of Shortcuts
Navigator knows all shortcuts and pushes to use
Fearful Freddie
Refusing to refactor code that you didn't write
The Anti-Mentor
Leaving the newbie alone while pairing
The Soloist
Works solo as much as possible
The Defactorator
Revert all refactorings the others did
ANTIPATTERNS
53. A writes a new test and sees that it fails
B implements the code to pass the test
B writes the next test
A implements it
And so on
Refactoring is done whenever needed
PING-PONG PAIRING
Well suited for applying TDD
If you aim to do remote pair
programming, start with ping-pong
54. GIT-PONG PAIRING
$ git remote add personA <URL>
$ git fetch personA
$ git checkout personA/master
$ git checkout -b feature/PA-231
add your changes and commit
$ git push personA feature/PA-231
A B
$ git checkout feature/PA-231
add your changes and commit
$ git pull personA feature/PA-231
55. A writes test
B writes production code
Repeat for 4-5 times
A refactors all
Switch roles
MICRO PAIRING
Similar to ping-pong, but you may pass a
succeeding test and switch the keyboard
56. It is an advanced skill, best suited for
seasoned, well-practiced teams
Any number of pairs might work on a
task at various times until it is complete
PROMISCUOUS PAIRING
A does pair programming with B
B does pair programming with C
C does pair programming with D
on the same task
even on the same day
57. 1 driver, multiple navigators
Big projector or big TVs
Switch every 15 minutes
MOB PROGRAMMING
The whole team works on the same thing, at the same
time, in the same space, and at the same computer
58.
59. ENJOYremember
whatever you do
do not forget to
https://www.flickr.com/photos/fraserspeirs/3394902061
Joe O'Brien and Jim Weirich while doing ruby code review