Recommended
More Related Content
What's hot
What's hot (20)
Similar to PhillyXP Pair Programming
Similar to PhillyXP Pair Programming (20)
Recently uploaded
Recently uploaded (20)
PhillyXP Pair Programming
- 1. Welcome to Anthony Sciamanna | @asciamanna
- 2. THE ORGANIZERS… Heather Blair Nick Goede Anthony Palumbi Mark Schell Anthony Sciamanna @phillyxp
- 5. FEATURE FACTORIES @phillyxp “Two people doing the work of one?? That’s a waste of expensive resources!” An antiquated factory mindset where number of keystrokes per hour and 100% utilization of developers are the goals Image courtesy of @johncutlefish
- 6. FEATURE FACTORIES If we measure the value we are delivering to customers there is a compelling argument for pairing Pairing often reduces the time to market for features @phillyxp
- 7. SELECTIVE PAIR PROGRAMMING @phillyxp “Most development tasks aren’t worth pairing on. We only pair when it is appropriate.”
- 8. SELECTIVE PAIR PROGRAMMING Developers only pair in very specific situations To onboard a new developer When someone gets stuck Effective pair programming is deceptively challenging The less you do it the less useful it is to you @phillyxp Sometimes pair programming doesn't "take" -- most frequently when it's framed as one programmer helping out another who's struggling. -Tim Ottinger, Agile Coach and Author
- 9. SELECTIVE PAIR PROGRAMMING CATCH-22 @phillyxp Developers think pairing all the time is too prescriptive Only pair for “special circumstances” Pairing occurs so infrequently developers never build pairing skills Without the skills to effectively pair developers fail to see its benefit in the day-to-day work
- 10. WHY SHOULD WE PAIR PROGRAM? Encourages team collaboration and team based design and development Improves / Creates opportunities for mentoring Drastically reduces onboarding time Flattens learning curves Knowledge travels through team quickly Builds trust / Team building Reinforces collective code ownership Eliminates Towers of Knowlege When paired with TDD creates a powerful workflow Results in higher quality code Limits WIP Encourages Swarming JIT code reviews (non-blocking code reviews) Interruption blocker Social pressure not to get distracted / Pairs stay in flow longer @phillyxp
- 12. 2. Write only enough production code to make the test pass 1. Create a failing unit test (not compiling counts as a failing test) 3. Refactor only when all unit tests are passing Ping Pong Pair Programmi ng @phillyxp
- 13. Nick Anthony Writes a failing test Makes the test pass Writes the next failing testMakes the next test pass Only when all tests pass either person can refactor Continue until both people agree there are no more tests to write @phillyxp
- 14. WORKSHOP Split up into pairs… Non-developers can pair with a developer or join a pair as a third person @phillyxp [When pairing] learning happens every minute of every day while actual work is being done. -Richard Sheridan, Author of Joy, Inc. and CEO of Menlo Innovations
- 15. WORKSHOP REPOSITORY SSH - git@github.com:PhillyXP/pair-programming- workshop.git HTTPS - https://github.com/PhillyXP/pair- programming-workshop.git @phillyxp
- 16. WORKSHOP DEVELOPMENT TASKS As a Bill Payer I want to pay my mortgage bill on the first business day that is on or after the due date As a Bill Payer I want to pay my water bill on the first business day that is on or before the due date As a Bill Payer I want to treat holidays as non-business days (external holiday service) As a Bill Payer I want to pay my electric bill on the first business day that is closest to the due date @phillyxp HINT TO GET STARTED: Create objects with public methods that take a date and return a modified date based on business rules
- 18. RESOURCES The Costs and Benefits of Pair Programming https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF Ping Pong Pair Programming http://anthonysciamanna.com/2015/04/18/ping-pong-pair- programming.html These books are excellent resources on pair programming @phillyxp
Editor's Notes
- Ideas for topics Want to speak Know someone who wants to speak REACH OUT TO US OR SEND A MESSAGE ON MEETUP We have all been in various leadership roles on XP teams in the past Looking forward to sharing our experiences and learning from all of you
- Pair Programming & TDD – and how they intersect in a practice called Ping Pong Pair Programming If you come back at the beginning of the year Nick and I will reprise our talk about Ping Pong Pair Programming that we gave at Alistair Cockburn’s Heart of Agile Conference. So this is a precursor to that talk that discusses this practice and how it addresses the challenges of traditional pair programming It ends with Nick and I working through these exercises that we’re going to do tonight Show of hands --- People who have paired - Of those people who have practiced TDD
- We wanted to talk briefly before the workshop about pair programming and its misconceptions Keep these in mind when pairing And if you want to take these practices back to your organization There are equally as many misconceptions about TDD – but that’ll be for another meeting I typically split pairing misconceptions into two categories
- Feature factory mindset - Comes out of orgs still rooted in “Old IT” ways of thinking Orgs measuring teams by output (optimizing for developer busyness, 100% utilization of developers) They are reluctant to try this practice - Knowledge work doesn’t work that way Evidence suggests opposite is true - Pairing is faster than developers working alone Agile Manifesto author Alistair Cockburn & his colleague Laurie Williams (from the university of Utah) Alistair Cockburn & Laurie Williams study – The Costs and Benefits of Pair Programming Measuring output – you would expect a 50% decrease if two people are really doing the work of one. They found an increase of total developer time of 15% However, the increase in the quality of the code and a decrease in bugs escaping to production, and less bugs found later in the development cycle made up for that 15%
- Higher quality code, less bugs escape to production, deliver value faster by limiting WIP and other techniques
- Teams who don’t pair tend to collaborate a lot less than teams who do Developers who say this insinuate that teams who pair all the time are somehow unprofessional. We pair when it’s appropriate THE PROBLEM – Software development is a social activity – teams who pair are much better collaborators and much more likely to collaborate than those who don’t. But when I observe these teams who “selectively pair” this is what I see the backs of people’s heads with headphones on and their face in the monitor. They don’t collaborate at all. Their team area resembles a library By contrast observing high functioning XP teams their work area is a hive of activity. Creative work is happening Becoming an expert in pairing helps you identify when you should or shouldn’t do it
- Why should we pair? Software development is a social activity – teams that pair are better collaborators and do it continuously
- TDD is a component of the workshop
- If anyone needs a TDD refresher, let’s discuss the basics quickly
- And now when TDD gets laid over Pair Programming it looks something like this
- Passing the laptop back and forth may seem awkward. And it is. This is our ideal setup