Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pair Programming - a pratical guide

A 15 minutes deck to introduce principles and guidelines for a correct pair programming practice.

  • Login to see the comments

  • Be the first to like this

Pair Programming - a pratical guide

  1. 1. PairProgramming Apracticalguide 11/5/2016 – Giuseppe Sorrentino
  2. 2. Objective Present pair programming as agile practice ◦ Definition and Advantages ◦ Roles and Duties Provide clear and slick guidelines to improve pair programming within the pod ◦ Restarting, Planning and Action ◦ Tips and Tricks PAIR PROGRAMMING – A PRACTICAL GUIDE 2
  3. 3. Definition PAIR PROGRAMMING – A PRACTICAL GUIDE 3 “Pair programming isa dialog between two people trying to…understand how to program better.”4 Itintegrateswell intoanagileenvironment because itallows:1 • to produce better software by continuous inspection ofcode; • to foster face-to-face communication.
  4. 4. Evidence 1 PAIR PROGRAMMING – A PRACTICAL GUIDE 4 Two programmers together vs. Twoprogrammers alone Two programmers together work more thantwice asfastand thinkof more thantwice asmanysolution toa problem astwo working together. Five experienced programmers individually vs. five couple of experienced programmers Groups completed the task40% more quicklyandeffectivelyby producing better algotithmsandcode inless time.
  5. 5. Roles
  6. 6. PAIR PROGRAMMING – A PRACTICAL GUIDE 6 Duties ◦ Active role on the keyboard/mouse ◦ Focuses on the code at hand: ◦ Syntax ◦ Semantics ◦ Algorithm ◦ Verbalise his thoughts ◦ Concentrates to pass the next test Driver ◦ No active role on the keyboard mouse ◦ Continually reviews the work ◦ Catches incidental mistakes ◦ Anything which needs further verification ◦ Overall code design ◦ Focuses on a strategic level ◦ Checks the consistency of the code being written with existent code ◦ Tracks if other changes are needed in different area of the code base ◦ Suggest design and algorithm enhancements Navigator They switch often (from 10 to 20 minutes) only by swiping the keyboard
  7. 7. ActivityTime 7 Findthequestions
  8. 8. PAIR PROGRAMMING – A PRACTICAL GUIDE 8 Example ◦ In this case is better a multiple if structure or a switch case? ◦ Which the most explicative name for this variable? Driver ◦ How will this fit with the rest of the code? ◦ Will this implementation require changes elsewhere? ◦ Could we design this program better? Navigator
  9. 9. Restarting, Planning and Action2 PAIR PROGRAMMING – A PRACTICAL GUIDE 9 Research recognized three main phases: • Restarting: when a couple is stuck • Planning: when a couple is deciding on their next actions • Action: when a couple is actively performing a task Guideline to drive these phases are in the notes.
  10. 10. Tips and Tricks1,2,3,4 PAIR PROGRAMMING – A PRACTICAL GUIDE 10 • Kill any distractor (browser, chats, notifications, etc.) • Use an editor both are familiar with • A good pairing time is four hours • Do not pair to execute systematic and repetitive tasks • Avoid to form always the same couples • Check that your partner is active • Healthy debate and avoid excess ego • Use an appropriate workspace layout (switch keyboard)
  11. 11. ActivityTime 11 Plusanddelta
  12. 12. PAIR PROGRAMMING – A PRACTICAL GUIDE 12 • Code quality • Speed • Learning • Familiarization Pair Programming Balance Conclusion
  13. 13. References PAIR PROGRAMMING – A PRACTICAL GUIDE 13 1. L. A. Williams and R. R. Kessler, “All I really need to know about pair programming I learned in kindergarten,” Communications of the ACM, vol. 43, no. 5, pp. 108–114, 2000. 2. M. Zarb, J. Hughes, and J. Richards, “Evaluating industry-inspired pair programming communication guidelines with undergraduate students,” in Proceedings of the 45th ACM technical symposium on Computer science education, 2014, pp. 361–366. 3. L. Williams, R. R. Kessler, W. Cunningham, and R. Jeffries, “Strengthening the case for pair programming,” IEEE software, vol. 17, no. 4, pp. 19–25, 2000. 4. M. Kircher, P. Jain, A. Corsaro, and D. Levine, “Distributed extreme programming,” Extreme Programming and Flexible Processes in Software Engineering, Italy, pp. 66–71, 2001.
  14. 14. Thankyou!