Download to read offline
An introduction to pair programming
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. Hold each otheraccountable
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. Everyone’s different –find what works
- 22.
- 23.
- 24. Pairing means we’llbe half as productive
- 25. Pairing is onlyuseful on complex tasks
- 26.
Editor's Notes
- #4 Two developers One computer One piece of work
- #6 Better design Pairs outperform for design tasks (Lui, Chan, & Nosek) Because pairs discuss what they’re doing New ideas
- #7 Better quality Pairs prodice fewer defects Testing & debugging many times more expensive than coding A pair is more likely to stand up to business for Pairs 15% slower 15% fewer bugs “Error free” code 70-85% 50% decrease in errors (30%-15%) Williams et al (http://www.economist.com/displayStory.cfm?Story_ID=779429)
- #8 Spreads knowledge Promiscuous knowledge (Neal Ford) - knowledge spreads across team Reduces bus count
- #9 Spreads knowledge (cont) domain knowledge architectural understanding keyboard shortcuts effective tools and techniques Collective ownership
- #10 Really fast feedback Constant feedback Solve problems early Stop each other from going down rabbit holes Detailed level: Your pair can give you feedback even faster than unit tests Often even faster than it takes you to notice compiler errors Strategic level: Your pair can see obstacles ahead before you can
- #11 Discipline Hold each other accountable: Clean code Following TDD. Write test first. Remember to refactor. Keeping acceptance criteria in mind Helps quality
- #12 Mentoring / learning Playing with better players – tennis Helpful for coaching – e.g. agile coaching, ramping up new team members Novice & novice Expert & expert Novice & expert
- #14 Roles - driver Focused on current task Types Narrates
- #15 Roles - navigator Keeps broader context in mind (strategic) Thinks Interjects
- #16 Talk and design Pair has design discussions as they go No discussions longer than 10 minutes without code
- #17 Swap roles Swap often Ping pong: Dev A writes failing test. Dev B implements and refactors. Writes next failing test. Just a way to do it until you get used to swapping often. Most important thing: swap often
- #18 Pair rotation Swap pairs often Pair for minimum ½ day, maximum 2 day Example: switch pairs after standup every day (could draw names from a hat)
- #19 Pair rotation (cont) 1 person stays with story (anchor) you can only stay once/rotation context update for the new pair swap today’s new pair is tomorrow’s context keeper tech lead can help pick effective pairs
- #20 You lose all the benefits of pairing when the same pair works together for too long.
- #23 http://martinfowler.com/bliki/PairProgrammingMisconceptions.html
- #24 People are often surprised by pairing People often try pairing badly: Sitting quietly and staring while someone else codes is not fun
- #25 "that would be true if the hardest part of programming was typing” (Martin) Pairing aids productivity by improving design, code quality, reducing bottlenecks and reducing defects. If Bob the developer is the only expert in area X of the application, then he will feel like he’s going slower when pairing with anyone else. But: a) This will even out over time. As the people Bob pairs with gain context, they will be able to go faster when pairing with Bob b) If something needs to be done in area X, but Bob is busy, the team is slowed down
- #26 No point having two people working on simple, repetitive code Writing boring, repetitive code is a smell. It generally means that a potential abstraction or design issue has been missed. Pairing will help finding and fixing this issue.
- #27 Got help from: Neal Ford (Slide deck on Agile engineering for 2012 Tech for Africa conference) Martin Fowler (http://martinfowler.com/bliki/PairProgrammingMisconceptions.html) Charles Haynes