Your SlideShare is downloading. ×
Distributed Pair Programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Distributed Pair Programming

425
views

Published on

Are two heads better than one? Isn't that twice as expensive? No, pairing goes almost twice as fast, but saves costly errors later. I can be done face to face or remote, and works for non software …

Are two heads better than one? Isn't that twice as expensive? No, pairing goes almost twice as fast, but saves costly errors later. I can be done face to face or remote, and works for non software projects as well.


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
425
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Table of ContentsPair programming is a practice in which two programmers work collaboratively at one computer on the same design, algorithm, or code. Prior research on pair programming has primarily focused on its evaluation in academic settings. There has been limited evidence on the use, problems and benefits, partner selection, and the general perceptions towards pair programming in industrial settings. In this paper we report on a longitudinal evaluation of pair programming at Microsoft Corporation. We find from the results of a survey sent to a randomly selected 10% of engineers at Microsoft that 22% pair program or have pair programmed in the past. Using qualitative analysis, we performed a large-scale card sort to group the various benefits and problems of pair programming. The biggest perceived benefits of pair programming were the introduction of fewer bugs, spreading code understanding, and producing overall higher quality code. The top problems were cost-efficiency, (work time) scheduling problems, and personality conflicts. Most engineers preferred a partner who had complementary skills to their own, who was flexible and had good communication skills.
  • for (int I = 0; i<10; i++); { // do stuff}
  • Transcript

    • 1. AgileBill Krebs UNM, UWADistributed Pairing IBM, ASPE Allscripts Dev 82 Agile 01 CSM, CSP MBTI, CVW IGTF, IGQIThe Distributed Agile Series Coaching distributed teams since 2009 Copyright © 2012 Agile Dimensions LLC
    • 2. Is this your team?Test Dev PM BA Allscripts Agile Academy
    • 3. Do Daily Meet Dev CI-Build [ Pair, UT, Refactor ] Test ( Refine ) Allscripts Agile Academy
    • 4. Pairing• Two people, one computer. Switch• Save ½ the bugs for +15% labor• Best benefits are intangible Allscripts Agile Academy
    • 5. Microsoft Research• “Pair Programming – What’s in it for me” Andrew Begel, Nachiappan Nagappan , Microsoft Research http://research.microsoft.com/pubs/75108/esem-begel-2008.pdfPair programming is a practice in which two programmers work collaboratively at one computeron the same design, algorithm, or code. Prior research on pair programming has primarilyfocused on its evaluation in academic settings. There has been limited evidence on theuse, problems and benefits, partner selection, and the general perceptions towards pairprogramming in industrial settings. In this paper we report on a longitudinal evaluation of pairprogramming at Microsoft Corporation. We find from the results of a survey sent to a randomlyselected 10% of engineers at Microsoft that 22% pair program or have pair programmed in thepast. Using qualitative analysis, we performed a large-scale card sort to group the variousbenefits and problems of pair programming. The biggest perceived benefits of pair programmingwere the introduction of fewer bugs, spreading code understanding, and producing overall higherquality code. The top problems were cost-efficiency, (work time) scheduling problems, andpersonality conflicts. Most engineers preferred a partner who had complementary skills to theirown, who was flexible and had good communication skills. Allscripts Agile Academy
    • 6. Top 10 Benefits (%)66 Fewer Bugs42 Spreads Code Understanding48 Higher Quality Code42 Can Learn from Partner30 Better Design22 Constant Code Reviews22 Two Heads are Better than One17 Creativity and Brainstorming14 Better Testing and Debugging13 Improved Morale Allscripts Agile Academy
    • 7. Formal Inspection• Different styles• Save ½ the bugs for +15% labor• Does it fit in a 3 day story? Allscripts Agile Academy
    • 8. $$ Series 1 Cost of change 100 90Place these: 80 Unit Test 70 Build 60 QA bug 50 40 Pairing 30 20 Customer bug 10 0 Inspection a b c d e f g hTime -> j i Allscripts Agile Academy

    ×