(Remote) Pair Programming as it was presented at 33rd Degree 4 charity at 13 October 2013, Krakow, Poland Programming is often something that is done in solitude. Problem solving is something that often is done in a group. Programming is always about problem solving. It is therefore natural to do programming in groups. The group must not be too large and there must be at least two persons to make up a reasonable group. A pair turns out as the natural choice. Some of the benefits with pair programming are - Problem solving - Continuous reviews - Quality - Learning - Lower project risks - Satisfaction Pair programming is most efficient when the pair sits next to each other. This is not always possible. I will therefore show how to setup a remote pair programming session and then do some programming with a remote partner. There is a myth that pair programming is twice as expensive as having one person solve each problem. The actual direct cost has been shown to be only 15% higher.

1. (Remote) Pair Programming
Thomas Sundberg
Consultant, Developer
Stockholm, Sweden
tsu@kth.se
@thomassundberg
http://thomassundberg.wordpress.com

2. Goal
Introduce pair programming
Show a live example
Discuss problems

3. History
Practised since the fifties
– Fred Brooks as grad student 1953 – 1956
Author of “Mythical man”

4. Why
Fun
Problem solving
Fast feedback

5. Problem solving
One person – one problem
Two persons – one problem

6. Your average developer?
http://www.flickr.com/photos/thebigdurian/

7. Spread knowledge
Introduce new developer
Handover

8. Knowledge management
“Our knowledge has
legs – it walks home
every day”
Leif Edvinsson

9. Knowledge management

10. Knowledge management
Keep you bus count above one

11. Learning
New programming language
New development environment
New development techniques
TDD

12. Teaching experience
One student – Ok solutions
Two students – Better
Three students – Can work
Four students – have never worked
Pairs must to be equal
– Not expert – Novice
– Novice – Novice

13. What drives change?
Feedback

14. Who does CI?
Why?
Feedback

15. Feedback loop
Length?
It depends

16. Bug report
6 months
Water fall project in Stockholm

17. Time scales
Customer
Manual tests
Code review
Continuous Integration
Test Driven Development
Pair Programming
Driving a car

18. eXtreme Programming
http://en.wikipedia.org/wiki/File:XP-feedback.gif

19. Conclusion
Better software through faster feedback

20. How?

21. Exercises
Katas
!Production code
Throw away after

22. Pair programming games
Ping pong
Far sight navigator
Silent

23. Ping pong
One driver
One navigator
Switch often
~Every second method

24. Far sight navigator
One driver
One navigator
Switch seldom

25. Silent
Ping pong
No talking
Perfect for remote...

26. Where?
Coding dojos
Code retreats
Remote
Want to pair with me?
Adi Bolboaca - Code Retreat 20 October 2012, Turku, Finland

27. TDD
Not necessary

28. ew
Economy
vi
Two persons
W
ro
ng
One computer

29. Economy
Two persons
One problem

30. Cost of long feedback?
Production bug
Bad performance
Car crash

31. Cockburn and Williams
XP 2000
15% slower then independent developers
50% less bugs
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

32. Remote

33. Scheduling
Doodle

34. Network
Reasonable
5 MBit is ok

35. Tools
Sound
View
Code

36. Tools
Sound – Skype
View – Skype
Code – Github
Ok, not great

37. Tools
Sound – Skype
View – Team Viewer
Shared computer
Great

38. Demo

39. Remote partner
Peter Kofler, 'Code Cop'
Vienna, Austria
@codecopkofler
http://www.code-cop.org/
Fanatic about code Quality. Currently on #CodeCopTour.

40. Exercise
String Calculator Kata
Given a string
Parse it
Calculate the sum
Example:
“1,2”
3
http://osherove.com/tdd-kata-1/

41. Live

42. Tips
Second screen for personal stuff
Line numbering
Good headset

43. Problems

44. Remote Pairing
Hard to sketch a solution
Time zones

45. Local Pairing
Personal hygiene
Clean clothes

46. Focus
Exhausting
No micro pauses
Plan for breaks

47. Pomodoros
25 minutes work
No interruptions
5 minutes break
http://www.pomodorotechnique.com/

48. Manager forbids Pairing
Critical bug in production
Been there
Tried that
Got the t-shirt

49. Anti pattern
Don't talk
Leave the pair
Don't explain what you did
Don't say what you want to achieve

50. Anti pattern
Rude
Fight about driving
Kidnap keyboard

51. Why
Problem solving
Feedback
Better quality
Fun
Not a goal – a tool

52. Conclusion
Better software through faster feedback

53. Resources
Skype – http://www.skype.com
TeamViewer – http://www.teamviewer.com
http://blog.code-cop.org/2012/08/remote-pair-practice.html
http://thomassundberg.wordpress.com/2012/06/15/pair-programing/
Pair programming illuminated
Google may be your friend...

54. (Remote) Pair Programming
Thomas Sundberg
Consultant, Developer
Stockholm, Sweden
tsu@kth.se
@thomassundberg
http://thomassundberg.wordpress.com