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.

Unleashed Power Behind The Myths: Pair Programming (CraftSummit15)

4,329 views

Published on

This is the material I presented at the very first Software Craftsmanship Conference CraftSummit in Turkey and in the region on 30th of May, 2015. I described how to pair program efficiently and how to embed pair programming to our development culture efficiently.

Published in: Software, Engineering
  • Nice !! Download 100 % Free Ebooks, PPts, Study Notes, Novels, etc @ https://www.ThesisScientist.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice !! Download 100 % Free Ebooks, PPts, Study Notes, Novels, etc @ https://www.ThesisScientist.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi there! Essay Help For Students | Discount 10% for your first order! - Check our website! https://vk.cc/80SakO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • nice, find more latest PPTs on www.ThesisScientist.com.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Unleashed Power Behind The Myths: Pair Programming (CraftSummit15)

  1. 1. Unleashed Power Behind The Myths PAIR PROGRAMMING
  2. 2. LEML ORHAN ERGLN Agile Software craftsman Developing software since 2001 Active member of Agile Turkey Founder of Software Craftsmanship Turkey Developer, Architect, Trainer, Coach, Leader Sony 8. eBay Alumni Managing Partner at ACIVI [III @| emiorhan (5) lemiorhanergin. coin @| emiorhan {écm
  3. 3. As software development professionals WE ARE BRAVE We have passion to code We have hope to complete on time We believe we have technical competency We Follow the processes we care rife / ' 7 . , it « . .. .. 1 — ' Floating stairs. Inca Trail Peru
  4. 4. As software development professionals WE ARE Bllllllli The codebase we work usually becomes legacy It takes too much time to learn the platform Few people knows everything, others suffer We spend majority of time for bug fixing NJ“ I r e ‘A » " —2.. ~:"> I n ' ” Floating stairs. Inca Trail Peru : i V. 5 . '4 | - q
  5. 5. l{(_2I .4 . l ‘ff 3'" I ief‘ i ; i l ‘. . ’ W) I -IAVN. A)l| ’.
  6. 6. WE TAKE UNNECESSARY RISKS
  7. 7. WE TAKE UNNECESSARY RISKS leave us alone! We do better and solve problems quicker when we work alone
  8. 8. WE TAKE UNNECESSARY RISKS We usually do the tasks that we feel comfortable and we have expertise on
  9. 9. WE TAKE UNNECESSARY RISKS We develop. we test and we deploy code without getting feedback from anyone
  10. 10. WE TAKE UNNECESSARY RISKS We think that we can learn everything we need by reading from internet
  11. 11. WE TAKE UNNECESSARY RISKS We try to teach the platforms and the way we develop software by giving trainings
  12. 12. WE TAKE UNNECESSARY RISKS We keep our knowledge as if it is the safeguard of our career
  13. 13. WE BELIEVE IN MYTHS
  14. 14. OUR CULTURE WILL COLLAPSE The more we ignore these risks and advocate our sloppy culture, the sooner we collapse
  15. 15. Wm? H? I] EH; WM] & @[l]E §l][l]Cifl. lE' oonlcselfi oouum $Zllll7E WGDEUJBR @El‘_/7l§. P[ll]lEll]'F LHFE
  16. 16. PAIR PROGRAMMING
  17. 17. PAIR PROGRAMMING 1 978-1 988 P. J. Plauger, one of the implementors of C: "At each terminal were two programmers! Of course. only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders. ’’ 1 995 “Developing in Pairs" pattern in Jim CompIien's book 2002 "Pair Programming Illuminated", by Laurie Williams and Robert Kessler, is the first book devoted exclusively
  18. 18. I l l - A W l'l I‘ I I I ' I I I ' 4 I I I 4 I V 1 V 4 LA Collective Code Ownership A [music lvouulnmuw Move People Ccafiffs Around 100% smug Unit Design Cmmm Change nveeed PTestsd Pmmem Pa" Help Run All Unit asse Next Task Pa" create Fiailrlfiid . New‘Unit - Tests 0;-Failed Up aUnit%_. Pair . T; -“_. Continuous fgftw Acceptance -I-est °9$*~"‘ProgrammIng New Integration Acceplance -I-est _ Functionality Teal Simple Complex Code Code Acceptance T st Refactor pasesed Mercilessly
  19. 19. PAIR PROGRAMMING Social Skill
  20. 20. ___j' http: .i-*". i"fii'sti'ound. corni”reviewi"Why—Eveiy—Staitup-Shou| d—Pair—Program Why Every Startup Should ~ Pair Program
  21. 21. lfthere's a company out there that knows "software development, " it's Pivotal Labs. Edward Hieatt and his colleagues at Pivotal come from the agile school ofdevelopment, and in their client work have noticed many startups begin to experience an erosion of their development culture as they grow in size. The solution, which Hieatt put forward at the First Round Capital CTO Summit, is bold: A culture built completely around pair programming.
  22. 22. lfthere's a company out there that knows "software development, " it's Pivotal Labs. Edward Hieatt and his colleagues at Pivotal come from the agile school ofdevelopment, and in their client work have noticed many startups begin to experience an erosion of their development culture as they grow in size. The solution, which Hieatt put forward at the First Round Capital CTO Summit, is bold: A culture built completely around pair programming. Software development is really about people and is a social activity. Because ofthis, the concept of pairing becomes the core unit of teamwork to build a software development culture upon, and provides infinite benefits when teams start to scale quickly. At Pivotal Labs, for instance, engineers are pair programming all day, every day. Here, pairing is the key culture builder.
  23. 23. PAIR PROGRAMMING CI] fie R8 1 mouse 1 keyboard 1 monitor 1 machine 2 developers
  24. 24. MANY PEOPLE HATE IT
  25. 25. STEPS To MAKE . . Have desire Define coding standards Have passioned for PROGRAMMING Practice and be patieelIIEn Y0 u R Inspect and adapt INDISPENSABLE PRAGTIGE
  26. 26. I t _ g ‘ , e. ; _ - "E3 ‘r —»t""‘. ~§? :31.“! '?“‘P~"§'. ::! ~‘eT‘ii'i? " '5' . "''= ''‘''’'€i '9 '
  27. 27. Strate ist NAVIG TOR Doesn’t dictate the code Programs out loud Thinks through problems Reviews code Does sanitg testing Reads and checks Tactician DRIVER COOBS Thinks about how to code better
  28. 28. 1O EASY
  29. 29. Select you pair iviselg Don't force people who don't like each other to pair Two juniors might not be a good idea
  30. 30. Start with a reasonably well- defined task before gou sit down This could be team—owned tasks have no designated owner
  31. 31. @ Agree on one ting goal at a time Pairing forces you to think and discuss about design and refactoring
  32. 32. Rely on gour partner and support him
  33. 33. Does that look correct to you’? Do you think this is a valid test’? What's next’? I Trust me! a Do you have any better idea? I suggest better names for variables and classes I suggest to Implement in smaller steps I suggest possible inputs that we haven't covered Let me give you some details about this technology
  34. 34. Sgnc up frequentlg Ask for agreement Ask if you miss something
  35. 35. ® Take a moment to celebrate
  36. 36. Rotate pairs in every so minutes Do not exceed 4-6 hours a day Understand not everything has to be paired
  37. 37. criticize the practice after each ciailg standup Write down what you did well and what you failed to do
  38. 38. Weeklg schedule the pairings Pairing full time is not practical 25% for 3 days in a week 50% for 2 days in a week Revisit how you pair after sprints Talk on pairing schedules daily
  39. 39. Programming i — ‘ ; Designing Reading Thinking Sea_rc_hing Deciding Programming . Designing 4*" at Reading V Thinking Searching Deciding
  40. 40. Besides, if people program solo, they are more likely to make mistakes, more likely to over design, and more likely drop the other practices, particularly under pressure. XP Explained
  41. 41. Higher qualitg in code Higher morale Better collaboration Shared knowledge : ‘.i'ic! :er to market Automatic code review Useful for training people Lower defect rates : ‘-aster defect removal Cannot force people Tiring Hard to setup common infra Hard to keep focus clash of egos Harder for introverts i~lo multiple committers Easy to do anti-patterns More effort on first 8 last sprint
  42. 42. If gou feel gou are the onlg one who knows something, do similar tasks in pairs
  43. 43. Technical leaders should pair more than ang of the team members to cultivate the culture
  44. 44. The worst wag to teach a technical topic is doing trainings. Work in pairs, especially in the first weeks of newcomers.
  45. 45. Know how to write tests, learn how to design bg tests, practice how to collaborate via tests
  46. 46. Superman I am fast, give me keyboard Absent-‘mind Ed I am too distracted The Back-Seat Driver Tons of non—trivial comments Learn The King of Shortcuts - Navigator knows all shortcuts and pushes to use l"O ramrnin E)_ g . . g _ g FearfulFreddie Refusing to refactor code that you didn't write The Anti-iiientor Leaving the newbie alone while pairing The Soloist Works solo as much as possible The Defactorator Revert all refactorings the others did
  47. 47. learn Pair l’ili'l: ‘i‘iii‘i’»'i‘if‘. i'i’i‘i‘i'; "'"" programming PRDMISCUDUS PAIRING types GIT PONG PAIRING MOB PROGRAMMING
  48. 48. Joe O'Brien and Jim Weirich while doing ruby code review https: //www. flickr. com/ photos/ fraserspeirs/3394902061
  49. 49. @LEM| llRHAN https: //www. linkedin. com/ in/ lemiorhan @LEM| llRHAN https: //twitter. com/ lemiorhan @LEM| DHHAN http: //wwwslideshare. net/ Iemiorhan LEM|0RHANERB| N.COM Official site having personal information LEMI ORHAN ERGIN gjmm AGILE SOFTWARE CRAFTSMAN www. acm-software. com
  50. 50. Iiicm LEMI ORHAN EROIN SOFTWARE CRAFTSlilAl ¥9‘lClllI0l‘Ilall

×