Pair Programming - Be the best pair you can be.
•Download as PPTX, PDF•
0 likes•510 views
David has had a unique experience as a software practitioner. David met (and eventually married) a lady who was in the process of writing a dissertation on collaboration during pair programming. Reviewing (and reviewing and reviewing) this dissertation in combination with his industry experience has provided David with some unique insights into the act of pair programming. This talk aims to distill those insights and provide you with some concrete mechanisms that you can bring to your next pairing session to ensure that it is more effective.
Recommended
More Related Content
Similar to Pair Programming - Be the best pair you can be.
Similar to Pair Programming - Be the best pair you can be. (20)
Recently uploaded
Recently uploaded (20)
Pair Programming - Be the best pair you can be.
- 1. David Morgantini davidmorgantini.blogspot.co.uk dmorgantini@gmail.com
- 2. Who Am I? David Morgantini Independent consultant Previously worked for: ThoughtWorks Government Digital Services Paid to write code for 9 years Focus on Tech Leadership, Agile Coaching & pragmatic delivery
- 3. Why are we here?
- 4. In Scope Better understanding of the practice of pair programming Concrete tips on how to be more effective while pair programming
- 5. Out of scope A discussion on whether pairing is a good practice Tips on how to convince your team to try/use pair programming An overview of all the research on pair programming
- 6. Overview Some Definitions Pairing patterns Intended benefits Avoiding disengagement
- 8. Common Definition Let’s solve this problem! Ok!
- 9. More definitions Let’s use the bits class to get some bobs That sounds good. Driver Navigator Pairing Session
- 10. Disengagement I am such a good developer! I haven’t a clue what’s going on. What’s for dinner?
- 11. Players in a pairing session I’ve worked on the milking functionality before. Glad he knows this code, I’ve never seen it before. Expert Novice
- 12. Players in a pairing session But I’ve never had to work the DevOps* Expert Novice * DevOps is not a thing Ah I know all about the DevOps*!
- 13. Players in a pairing session But I’ve never had to work the DevOps* Novice Expert * DevOps is not a thing Ah I know all about the DevOps*!
- 15. There can only be one … and we add an implementation here … You missed a semi-colon.
- 16. There can only be one Jerk. Keeps hogging the keyboard. And my neck hurts. … and now watch as I type these seven new classes …
- 17. Two keyboards … let me explain by driving for a bit! Ah, now I understand what you’re trying to say!
- 18. Two keyboards STOP TYPING DAMNIT! WE DO THIS!
- 19. A Laptop I don’t understand, I can’t see. Pair programming is stupid. … the gubbins go with the bits and bobs…
- 20. Mirrored laptop I still don’t understand but at least now I can see! Pair programming rocks! … and then we connect the bobs to the ESB via the night service …
- 21. Dual station … You’ll be able to connect to the gubbins! We ROCK! … so you’re saying if I catch the night service at line 135 …
- 22. Dual station There is a problem there! La la la, looking at my monitor, don’t know what you’re talking about
- 24. What does the research say? Based on bug count, pairing is equivalent to solo programming. Pair Programming makes a major positive difference. Pair programming is a hindrance. Don’t use it.
- 25. I would be more interested in looking at the patterns of interactions that can lead to the benefits or how they are lost. Pair vacation taking is AWESOME!
- 26. Intended benefits of pairing Economics Design quality Developer satisfaction Learning/Knowledge transfer Team building and communication
- 27. Economics … create loads of gubbins! … use the gubbin factory to … Two people doing one person’s work!? Yep! Fewer bugs & better design should lead to lower long term costs!
- 28. Quality But how do we connect the gubbins without one? Maybe an ESB is a bad idea? Excellent, keep up the good work! No new bugs to report, sir!
- 29. Developer satisfaction Ok, no ESB. Let’s use a light-weight message queue instead Great idea! Today was AWESOME! WE ROCK! HIGH FIVE
- 30. Learning/Knowledge sharing I know this code! I paired with Jill! Good thing we pair cause I don’t know what a gubbin is!
- 31. Communication This would be a pain if we had to use an antiquated communication method. I hear ya!. E-mail is so 2005.
- 32. Systemic Benefits WE WE ARE ARE BUILDING BUILDING BETTER BETTER SOFTWARE! SOFTWARE!
- 34. Disengagement I am such a good developer! I haven’t a clue what’s going on. What’s for dinner?
- 35. Mutually agreed disengagement … and while you do that I’m going to refactor the gubbin factory. I’m going to connect up the message queue
- 36. Expert-Novice *whistling* I’m so confused Expert Novice
- 37. Expert-Novice Do you understand? No. Can you please explain more? Expert Novice
- 38. Reasons for disengagement 1) Type of work 1) Unfamiliar working environment 2) Interruptions 3) Time pressure 4) Social pressure
- 39. Type of work I don’t think that this work needs a pair. Ya. I’m not really able to effectively contribute
- 40. Suggestions 1) Consider tiny tasking 2) Break up the pair 3) Ask yourself if the work needs a pair 4) Expert: Ensure the novice is driving
- 41. Uncomfortable dev environment I love EMACS!1! Um… I can’t use this insane text editor
- 42. Suggestions 1) Make each pair feel ‘at home’ Dual monitors/keyboard etc… Team IDE standardization 2) Expert: Take the comfort hit if the goal is learning
- 43. Interruptions Ha ha! Free from the old ball and chain! When the cat’s away, the ESB returns! Sorry, I forgot. You didn’t put a new cover sheet on your TPS report!
- 44. Interruptions … and then remember to add one to combat the naming problems … I don’t know what’s going on anymore…
- 45. Suggestions 1) Try not to disrupt an in progress session 2) Complete any in progress discussion before acknowledging interruption 3) Plan for longer interruptions 4) Re-establish mutual context when interruption is complete
- 46. Time pressure I feel the need… the need for speed. OMG. I lost him 25 minutes ago. Expert Novice
- 47. Suggestions 1) Plan novice pairing time into estimation 2) Expert: Verbalize progress and ask for feedback
- 48. Social pressure … and finally, once we have connected the message queue… I don’t understand. But I don’t want to look stupid by asking a question
- 49. Suggestions 1) Expert: Give novice partner some time to consider solutions alone before development starts 2) Novice: Stop your partner when you don’t know what’s going on 3) Expert: Encourage your partner to drive 4) Establish mutual context before starting development
- 50. Thank You! What an interesting group of research subjects. So did you learn anything today? I was busy playing candy crush. He made 5 mistakes!!!! GET BACK TO WORK! I DON’T PAY YOU TO SIT AROUND AND TALK!
Editor's Notes
- What does the research say? Pairing has been shown to cost more with few benefits and cost less with loads of benefits. Why??
- What does the research say? Pairing has been shown to cost more with few benefits and cost less with loads of benefits. Why??
- Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are 15% slower than two independent individual programmers, while "error-free" code increased from 70% to 85%. Since testing and debugging are often many times more costly than initial programming, this is an impressive result.[6] Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early.[7]
- Two developers will bring Different view points to the problem Different methods to find information relevant to the problem A larger number of differing solutions than a single developer Therefore, are less likely to select a poor solution
- Developers are happier when they are confident in their solutions Developers are more confident in their solutions when pairing Developers are happier when pairing
- Constant knowledge sharing between developers in a pair Each developer on a team pairs with all other developer which helps to break down knowledge silos Instant feedback on coding style and techniques 2 things – team knowledge sharing 1- Personal learning
- Developers share problems with each other Less likely to have ‘hidden agendas’ Communication flow is increased within the tea ‘Common code ownership’
- These benefits are systemic They are not useful in judging a given pairing session There is a degree of ‘faith’ you have to put into the practice
- Have the highest incidence of ‘bad’ disengagement Both members of the pair need to be mindful of disengagement
- Pay attention to your pair Understand the context of the pairing session Learning Completing the work quickly
- Not all work needs a pair Or, more accurately, not all work is most effective in a pair: Diagnosing some bugs Simple UI fixes Research Some parts of most stories
- Driving helps ensure engagement An uncomfortable work environment leads to not driving Ergo, the more comfortable you are to drive, the more likely you are to stay engaged
- Double edged sword It’s very easy to lose track of progress if one member of the pair is interrupted Losing track of progress leads to ‘bad’ disengagement
- Double edged sword It’s very easy to lose track of progress if one member of the pair is interrupted Losing track of progress leads to ‘bad’ disengagement
- Mostly an issue in Expert-Novice constellations The expert will want to move faster than the novice is capable of keeping up
- It’s hard to pair with experienced people Don’t want to seem stupid Don’t want to slow the pair down Less likely to ask questions required to stay engaged