Pair Programming
About me <ul><li>ศิริวัฑฒ์ จิตต์หรรษา </li></ul><ul><li>Siriwat Jithunsa </li></ul><ul><ul><li>siriwatj@gmail.com  </li></...
Objective <ul><li>To give an overview about Pair Programming and its benefits which could make you curious and may want to...
Agenda <ul><li>History </li></ul><ul><li>The Mechanics of Pairing </li></ul><ul><li>Some researches </li></ul><ul><li>Bene...
<ul><li>Xtreme Programming advocates  pair programming on all production code . </li></ul>
Pair Programming History <ul><li>Larry Constantine (1995) -  </li></ul><ul><ul><li>Called it &quot; Dynamic Duo &quot; dev...
The Mechanics Of Pairing
Pair Programming Chair No, Thanks.
The Mechanics Of Pairing <ul><li>Two developers work on the same machine. Both have keyboard and mouse. </li></ul><ul><li>...
The Mechanics Of Pairing <ul><li>The roles switch either every hour, or whenever really. </li></ul><ul><li>~ 4-6 hours a d...
Effects of pair programming at the development team level: an experiment <ul><li>Had  29% lower project productivity  for ...
Effects of pair programming at the development team level: an experiment <ul><li>Code contained  8% less defects per use c...
Martin Fowler said … <ul><li>When people say that Pair Programming reduces productivity, I answer &quot; that would be tru...
Benefits <ul><li>Good for learning and training </li></ul><ul><ul><li>Deeper understanding of  why ,  how  and  what  was ...
Industry Metrics <ul><li>Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are...
Why it works? <ul><li>Two people have differing specialities, these skills are transferred. </li></ul><ul><ul><li>“ everyb...
Why it works? <ul><li>It's less likely to contain bugs and hacks and things that cause maintenance problems later. </li></...
Why it works? <ul><li>It gets developers talking and communicating ideas in the common language of code. </li></ul><ul><li...
Pair Programming Patterns <ul><li>Driver-Navigator </li></ul><ul><li>Mouse-Keyboard </li></ul><ul><li>Ping-pong </li></ul>
Driver-Navigator <ul><li>Driver </li></ul><ul><ul><li>Is the person typing the code </li></ul></ul><ul><li>Navigator </li>...
Mouse-Keyboard <ul><li>Driver:  </li></ul><ul><ul><li>Uses keyboard </li></ul></ul><ul><li>Navigator:  </li></ul><ul><ul><...
Ping-pong <ul><li>Driver:  </li></ul><ul><ul><li>Writes code </li></ul></ul><ul><li>Navigator:  </li></ul><ul><ul><li>Writ...
Challenges <ul><li>To get the buy-in on doing pair programming from Management </li></ul><ul><ul><li>Understand the benefi...
Tips <ul><li>Agree on one tiny goal at a time </li></ul><ul><ul><ul><li>Using Unit Tests </li></ul></ul></ul><ul><li>Sync ...
Tips <ul><li>TDD - Write a unit test first. This will help you and your partner to agree on the goals. </li></ul><ul><li>S...
Q: Expert & Junior <ul><li>Possible Issues: </li></ul><ul><ul><li>A boring lecture </li></ul></ul><ul><ul><li>A one-man sh...
Record Your Communication In The Code <ul><ul><li>If the junior can't understand some bits of the code </li></ul></ul><ul>...
Jeff Atwood –  Coding Horror “ When your code is reviewed by another human being -- whether that person is sitting right n...
Resources <ul><li>Web Sites: </li></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>I Love Pair-Programming </l...
Thank You <ul><li>& Special Thanks to my team for real-world input, experience, and support </li></ul>
Discussion / Q&A
Upcoming SlideShare
Loading in …5
×

Pair Programming

2,328 views
2,121 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,328
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Pair Programming

    1. 1. Pair Programming
    2. 2. About me <ul><li>ศิริวัฑฒ์ จิตต์หรรษา </li></ul><ul><li>Siriwat Jithunsa </li></ul><ul><ul><li>siriwatj@gmail.com </li></ul></ul><ul><ul><li>Thomson Reuters </li></ul></ul>
    3. 3. Objective <ul><li>To give an overview about Pair Programming and its benefits which could make you curious and may want to try in your team. </li></ul><ul><li>To share and discuss about challenges and tips on doing pair programming. </li></ul>
    4. 4. Agenda <ul><li>History </li></ul><ul><li>The Mechanics of Pairing </li></ul><ul><li>Some researches </li></ul><ul><li>Benefits </li></ul><ul><li>Why it works? </li></ul><ul><li>Pair Programming Patterns </li></ul><ul><li>Challenges </li></ul><ul><li>Tips </li></ul><ul><li>Discussion / Q&A </li></ul>
    5. 5. <ul><li>Xtreme Programming advocates pair programming on all production code . </li></ul>
    6. 6. Pair Programming History <ul><li>Larry Constantine (1995) - </li></ul><ul><ul><li>Called it &quot; Dynamic Duo &quot; development </li></ul></ul><ul><li>Nissim Hadar (1996) - </li></ul><ul><ul><li>I was leading a team of 4 programmers working on a flight simulator in 1996. Each programmer was assigned a separate aircraft system. </li></ul></ul><ul><ul><li>The programmers came to me and told me that, as they were always helping each other (this was FORTRAN on a weird system...), they wanted to work in pairs on each system. </li></ul></ul><ul><ul><li>This seemed inefficient to me at the beginning, but the big improvement came when the weaker programmers improved within a short time and there were fewer bugs in the fixed time we had for the project. </li></ul></ul>
    7. 7. The Mechanics Of Pairing
    8. 8. Pair Programming Chair No, Thanks.
    9. 9. The Mechanics Of Pairing <ul><li>Two developers work on the same machine. Both have keyboard and mouse. </li></ul><ul><li>At any given time one is driver and the other navigator. </li></ul><ul><li>The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. Real-time peer review. </li></ul>
    10. 10. The Mechanics Of Pairing <ul><li>The roles switch either every hour, or whenever really. </li></ul><ul><li>~ 4-6 hours a day </li></ul>
    11. 11. Effects of pair programming at the development team level: an experiment <ul><li>Had 29% lower project productivity for the first three or four use cases. </li></ul><ul><li>The inefficiency was probably caused by: </li></ul><ul><ul><li>the learning time </li></ul></ul><ul><ul><li>involved in getting familiar with new people and the pair programming practice. </li></ul></ul><ul><li>Later teams spent 5% less effort than the Solo Programming teams for implementing the use cases. </li></ul>http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1541842
    12. 12. Effects of pair programming at the development team level: an experiment <ul><li>Code contained 8% less defects per use case </li></ul><ul><li>In the end of the project they delivered systems with a lower number of defects per use case. </li></ul><ul><li>Had slightly better design quality based on the method size and complexity metric </li></ul>
    13. 13. Martin Fowler said … <ul><li>When people say that Pair Programming reduces productivity, I answer &quot; that would be true if the most time consuming part of programming was typing &quot; </li></ul>
    14. 14. Benefits <ul><li>Good for learning and training </li></ul><ul><ul><li>Deeper understanding of why , how and what was done </li></ul></ul><ul><li>Better Quality </li></ul><ul><ul><li>Fewer bugs </li></ul></ul><ul><ul><li>Instant validation of ideas </li></ul></ul><ul><ul><li>Adherence to team conventions </li></ul></ul><ul><li>Increased productivity </li></ul><ul><ul><li>Fewer interruptions - better focus </li></ul></ul><ul><ul><li>pushing each other and motivating to achieve best results </li></ul></ul><ul><ul><li>Less procrastination and wasting of time </li></ul></ul><ul><li>Improved morale </li></ul><ul><ul><li>Greater confidence that their work is correct. </li></ul></ul><ul><li>Better discipline and time management </li></ul><ul><ul><li>Less likely to skip writing unit tests, spend time web-surfing or on personal email </li></ul></ul>
    15. 15. Industry Metrics <ul><li>Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs (N.B.: The original study showed that 'error-free' code went from 70 % to 85 %; it may be more intuitive to call this a 50 % decrease of errors, from 30 % to 15 % ). Since testing and debugging are often many times more costly than initial programming, this is an impressive result. </li></ul><ul><li>http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF </li></ul>
    16. 16. Why it works? <ul><li>Two people have differing specialities, these skills are transferred. </li></ul><ul><ul><li>“ everybody has some expertise, some knowledge or ideas that are worth sharing .” </li></ul></ul><ul><li>Ad-hoc training occurs as one person shows the other some tricks and techniques, nice workarounds, etc. </li></ul><ul><li>Both developers are fully aware of the code, how it works, and why it was done that way. </li></ul>
    17. 17. Why it works? <ul><li>It's less likely to contain bugs and hacks and things that cause maintenance problems later. </li></ul><ul><li>Chances are the code is better than one developer working alone, as there was somebody watching. </li></ul><ul><ul><li>It is impossible to ignore the reviewer when he or she is sitting right next to you. </li></ul></ul>
    18. 18. Why it works? <ul><li>It gets developers talking and communicating ideas in the common language of code. </li></ul><ul><li>The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code. </li></ul><ul><ul><li>Continuous Code Review </li></ul></ul>
    19. 19. Pair Programming Patterns <ul><li>Driver-Navigator </li></ul><ul><li>Mouse-Keyboard </li></ul><ul><li>Ping-pong </li></ul>
    20. 20. Driver-Navigator <ul><li>Driver </li></ul><ul><ul><li>Is the person typing the code </li></ul></ul><ul><li>Navigator </li></ul><ul><ul><li>Reviews what the driver is writing </li></ul></ul><ul><li>Roles should switch frequently </li></ul><ul><ul><li>~1 hour at a time in each role </li></ul></ul>
    21. 21. Mouse-Keyboard <ul><li>Driver: </li></ul><ul><ul><li>Uses keyboard </li></ul></ul><ul><li>Navigator: </li></ul><ul><ul><li>Uses mouse </li></ul></ul><ul><li>Benefits: </li></ul><ul><ul><li>Makes sure everybody is contributing/engaged </li></ul></ul>
    22. 22. Ping-pong <ul><li>Driver: </li></ul><ul><ul><li>Writes code </li></ul></ul><ul><li>Navigator: </li></ul><ul><ul><li>Writes tests </li></ul></ul><ul><li>Benefits: </li></ul><ul><ul><li>Another developer evaluates functionality </li></ul></ul>
    23. 23. Challenges <ul><li>To get the buy-in on doing pair programming from Management </li></ul><ul><ul><li>Understand the benefits and cost </li></ul></ul><ul><li>Everyone has to WANT to pair. </li></ul><ul><ul><li>they all at least need to be curious enough about it to give it a genuine shot - attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work. </li></ul></ul><ul><li>Environment </li></ul><ul><ul><li>The developers need to be side by side, the same distance from the monitor (which needs to be large). </li></ul></ul><ul><ul><ul><li>You might need more chairs. </li></ul></ul></ul><ul><li>Personal Preferences </li></ul><ul><ul><li>Hygiene can be a serious problem. </li></ul></ul><ul><ul><li>Timing </li></ul></ul>
    24. 24. Tips <ul><li>Agree on one tiny goal at a time </li></ul><ul><ul><ul><li>Using Unit Tests </li></ul></ul></ul><ul><li>Sync up frequently (Communicate, Ask & Listen, Compromise or take your stand) </li></ul><ul><ul><ul><li>Make sure you both know what the other one is working on and thinking </li></ul></ul></ul><ul><li>Switch roles often (at least once an hour) </li></ul><ul><ul><ul><li>If you’re stuck or frustrated, try switching roles </li></ul></ul></ul>
    25. 25. Tips <ul><li>TDD - Write a unit test first. This will help you and your partner to agree on the goals. </li></ul><ul><li>Switch partners when you start a new iteration </li></ul><ul><li>Schedule breaks if necessary </li></ul><ul><ul><ul><li>Decide to take a 5 minute coffee break if things are getting tense or you need a second to think </li></ul></ul></ul><ul><ul><ul><li>Take a moment to celebrate </li></ul></ul></ul><ul><li>Getting feedbacks from your team </li></ul>
    26. 26. Q: Expert & Junior <ul><li>Possible Issues: </li></ul><ul><ul><li>A boring lecture </li></ul></ul><ul><ul><li>A one-man show game - the expert monopolizes the keyboard and never let the other drive it. </li></ul></ul><ul><li>Solutions: </li></ul><ul><ul><li>Communicate. </li></ul></ul><ul><ul><ul><li>Junior should ask wisely and Expert should answer wisely. </li></ul></ul></ul><ul><ul><li>Record Your Communication In The Code </li></ul></ul>
    27. 27. Record Your Communication In The Code <ul><ul><li>If the junior can't understand some bits of the code </li></ul></ul><ul><ul><li>And then asks on it </li></ul></ul><ul><ul><li>The expert notices that he failed to make the code clear at every point </li></ul></ul><ul><ul><li>The pair tries &quot;together&quot; to refactor the bits into a new method with an explanatory name </li></ul></ul><ul><ul><ul><li>remember that when you use comments as the last resort, the code quality will improve much more </li></ul></ul></ul><ul><ul><li>So that next time other pairs see the bits, there be no need to ask/explain/explore whatever but to learn fast. </li></ul></ul>
    28. 28. Jeff Atwood – Coding Horror “ When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. ”
    29. 29. Resources <ul><li>Web Sites: </li></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>I Love Pair-Programming </li></ul></ul><ul><ul><li>Pair Programming vs. Code Reviews </li></ul></ul><ul><ul><li>Pair programming. What researches say on the costs and benefits of the practice. </li></ul></ul><ul><li>Book </li></ul><ul><ul><li>Pair Programming Illuminated </li></ul></ul>
    30. 30. Thank You <ul><li>& Special Thanks to my team for real-world input, experience, and support </li></ul>
    31. 31. Discussion / Q&A

    ×