Pair Programming: does it really work?

Pair Programming is an agile practice and numerous studies show its benefits for education. Does It really work? Is it really such a good methodology to have two devs on the same task? What are the best strategies to perform an efficient pair programming section? The presentation will show how pair programming could improve design quality, reduce defects and staffing risk, enhance technical skills and improve team communications. On the other hand it will discuss how this method causes an increase of development-time cost of about 15%, however reducing the need for bug fixing.

Transcript

1. Pair Programming: Does it Really Work?
2. Mirko Urru ( @MirkoUrru) Software Engineer @DellEMC Cork About me
3. Agenda What is Pair Programming? Why Pair Programming? When is it working? Cost of pair programming
4. What is Pair Programming? 1
5. “ “Pair programming is an Agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.”
6. Why Pair programming? 2
7. Why Pair Programming? Code Quality Instant code review Learning Sharing knowledge
8. When is it working? 3
9. Rules for a good pair programming section 1. Agree on the physical environment beforehand 2. When talking about code, always refer to line number and file name 3. When disagreeing, talk in terms of benefit 4. Switch role frequently (a Tomato each)
10. When do pair programming New hires Complex tasks Early stage project Approaching new technologies
11. Best case scenario Let me write this test first.. Sure, I’ll write the method then… Why don’t we use this library? Oh cool, we can re-use it in this method later.. This class has too many methods, let me refactor it… Perfect, all tests are still green … Cool, do you know this tool to test code coverage?
12. Performance Indicators ◉Satisfaction ◉Problem solving ◉Learning
13. No-Performance Indicator ◉Lack of engagement ◉Silence ◉“Watch the Master”
14. Pair-programming is NOTthe right tool for every task and it is NOT suitable for everyone !
15. Costs of Pair Programming 4
16. 15% The development cost for these benefits is not the 100%, but is approximately 15%. The Costs and Benefits of Pair Programming https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
17. Relative Time: One Individual vs Two Collaborators 100% 100% 100% 150% 120% 117% Program1 Program2 Program3 1 Dev 2 Devs Time
18. 15% Less defects The Costs and Benefits of Pair Programming https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
19. Post Development Test Cases Passed 73% 78% 78% 78% 86% 88% 87% 94% Program1 Program2 Program3 Program4 Individual Pairs
20. Experiment q 50,000 lines of code (LOC) q Speed of 50 LOC/hour q Individual will take 1000 hours q Pairs 15% longer so 1150 hours (+150 hours)
21. Industry Average: errors per 1000 lines of delivered code Industry Average: about 15 – 50 (Clean Code) Microsoft: 10-20 Nasa: 0 Experiment
22. Example N°Defects per 1000 LOC * Thousand code lines Individual: 30 * 50 = 1500 Pair: 25.5 * 50 = 1275 225 less defects Single bugfix average time fixing: 10 hours 2250 hours > 150 extra hours for a pair section
23. Summary ü many mistakes get caught ü the final defect content is statistically lower (continuous code reviews) ü the designs are better and code is shorter (ongoing brainstorming and pair relaying); ü the team solves problems faster (pair relaying); ü people learn significantly more, about the system and about software development (line- of-sight learning); ü the project ends up with multiple people understanding each piece of the system; ü the people learn to work together and talk more often together, giving better information flow and team dynamics;
24. 86% Developers prefer to work alone Forbes.com
25. Any questions ? You can find me at ◉ @MirkoUrru ◉ Mirko.urru@me.com Thanks!