Test Driven Development: By Example

Roundup '12 - (Variations in) Pair Programming (Variations) **Fully formatted shownotes can always be found at http://javaposse.com

Pair Programming is hard, because it’s social. In this session hosted by Dianne Marsh and Andrew Harmel-Law we discuss different approaches to adopting this agile practice. Thanks to Todd Costella, Jack Leow, Eirik Bjørsnøs, Chris Marks, D.J. Hagberg, Brian Gray and Victoria Vickers for their valuable input.

Recorded at the Java Posse Roundup 2012 in Crested Butte, CO

Thanks to Andrew Harmel-Law for production help.**

  • A Pair Programming Tarot
  • The Pair Programming Rules (from extremeprogramming.org)
  • The Pair Programming Idioms (from extremeprogramming.org)
  • A Pair Programming Tarot Lightning Talk (youtube)

  • A Pair Programming Tarot Slides (slideshare)

  • “Two Brains and Two Sets of Hands”

  • Pair programming with personal input devices,

  • but shared and mirrored screens

  • Adoption

  • Developer led versus “militant” “all-pair-programming-all-the-time”

  • In our experience its not always appropriate to use it

  • The Importance of the physical space

  • The desk and chair layout

  • The problem with “the rest of your job”

  • How do you fit in other, non-pair tasks like email, calls, lunch, etc?

  • Pair Programming Remotely ON PURPOSE

  • Google Hangouts
  • Plus “your own space”
  • Good relationships make this a minor / non-existent barrier to success

  • Not every day, also work co-located regularly

  • The “@Debt thing” example

  • The @Debt project Wiki and Code (Kenai)
  • Windows Livemeeting
  • Importance of good relationships

  • And importance of ability to think out loud

  • Impact on Planning

  • Plan in pairing at estimation stage
  • “2x2” - 2 people for 2 hours
  • Record the time for both people for the whole time
  • Problem: How to handle it if not planned in - do we both record time against the task?
  • Option 1: stop estimating at Task / hour level
  • Just focus on Story Points / Sprint for your team
  • You can still break a Story into Tasks to visualise your work and allocate it, but don’t estimate them

  • This is slightly “black box” Sprint-level progress reporting

  • Pairs of different skill levels

  • It works best with people of similar skill levels

  • But this is not the only way

  • Benefits of onboarding and knowledge sharing

  • But you can’t tolerate egos

  • Which you are more likely to see in the expert

  • Remember this skills transfer ought also to include the skills of pairing itself

  • Mindfull Programming
  • Being aware of yourself as you program
  • And also being aware of the other half of your pair as you program

  • Teach without making the other half feel they are stupid

  • How to pair up?

  • What if you have odd numbers of people?
  • Rotate pairs every day

  • Culture of “you must pair with everyone else within a Sprint”

  • Just let them decide themselves

  • On a task-by-task basis

  • On an ad-hoc basis

  • Sitting next to someone while they program is not pair programming

  • Letting go of Driver / Navigator

  • When you’re really flowing as a pair, you’re both Driving and both Navigating
  • You’re really collaborating
  • How to get there?
  • Use the Ping Pong Idiom: One person writes a test, the other person implements it
  • Break through egos by writing a test which breaks the thing just written

  • Liked this on Code Retreat

  • But what if the skill gap is too large?

  • Don’t be dogmatic

  • If it’s not working, just STOP

  • Pair Programming in Interviews

  • Chance to reduce stress of interviewee at every opportunity

  • Adoption Techniques (when none of you are experienced Pair Programmers)

  • Deliberate practice
  • Workshop with tasks (the TDD Katas are good for this)
  • A few lightning talks before (about pairing approaches)
  • Experiment and mix the pairs

  • Reduce the amount of “reality”

  • Corey Haines

  • Code Retreat - Jim Hurne gives a lightning talk about Code Retreats at JPR2011

  • Challenging the assumptions of “different skill levels”

  • This introduces the ego right there
  • Instead value the spectrum of skills that each person comes from

  • John the UI Guy’s website: www.ilikepixels.co.uk

  • Managing the bits in between the pair programming sessions

  • I.e. synching the non-programming schedules of the pair
  • Nothing in the available literature seems to talk about this
  • But how do you manage it?
  • One of the pair is almost always having to think about personal life stuff they need to do
  • Explicitly schedule it it

  • And also don’t pair all time - it’s HARD WORK

  • Difference from working individually

  • Individually you can turn lots of your brain off - e.g. the social bit
  • But in Pair Programming this is very much on
  • WHich is draining

  • But it can also be addictive

  • Certified Scrum Developer

  • www.scrumalliance.org/pages/certified_scrum_developer
  • Ron Jeffries

  • Chet Hendricksen

  • Pairing with non-Programmers

  • Business experts
  • Testers

  • Operations

  • Non-Verbal Cues

  • Pairing when one person is standing and the other sitting
  • Body language has a role to play

  • Home field advantage - always pairing at one half of the pair’s desk

  • Pairing Stations

  • Gets round the problem of using some else’s setup
  • Different IDE setup
  • Different keyboard

  • Mac / Windows

  • Don’t make me think

  • International Pairing

  • The problems of Finnish keyboard mappings

  • Sharing code with a DVCS (like git) to get round the someone else’s setup problem

  • “Push” and share the code when you swap

  • Makes you think in logical pieces of work

  • Frequency of Control Switching

  • “It depends”

  • “Trio Programming”

  • One coding, two writing tests

  • Everyone has a different views of the world

  • Advantage of cycling pairs - everyone knows all the code

  • And more than the code; involve the DBA too

  • Disadvantage of cycling pairs - context switching

  • to begin with this is the case
  • but then you got a better view of the codebase

  • the code looked like a team had written it

  • The positive social pressure of pairing

  • Builds better code
  • Counters the risk of over-engineering
  • The angel on your shoulder

  • N.b. it can go the other way - but most folks are aware of our own failings

  • Lack of Resources

  • pairwith.us (not “pairwith.me” as mentioned)

  • How much Pairing?

  • You can burn out
  • It can be relentless when you’re learning it
  • It challenges a lot of your introversion
  • Take small bites

  • Find the pair tasks

  • Breaking down tasks

  • At Sprint planning
  • It’s an art
  • Keep breaking things down

  • Waiting until the “last responsible moment”

  • Remember it’s about finding the sweet spot for your team - it’s the variations

  • Team dynamic specific
  • Project specific
  • Company culture specific

  • It depends

  • A culture of self-organising teams will avoid lots of the potential problems you might find in adoption

  • Test Driven Development

  • Red / Green / Refactor - it is a very deliberate process
  • Test Driven Development: By Example (Kent Beck) - Amazon
  • Remember the “D” stands for “Driven” - designing the API at the lowest level
  • There is a lot of emotional language in the book
  • The “smallest possible increment” adoption method
  • Martin Fowler’s Afterword to “TDD: By Example” - Google Books
  • TDD as if you meant it - http://www.infoq.com/presentations/TDD-as-if-You-Meant-It
  • Stop and think about it
  • Are you in the proper state of mind to be developing? - E.g. are you too tired?
  • Check by writing tests

Thanks * Libsyn.com - http://www.libsyn.com - for hosting and bandwidth * Feedburner.com - http://www.feedburner.com - for feed redirect * Kirsty Doherty, Amy Ehmann for Java Posse artwork * Theme Music: + Opening - "Java" the parody song Copyright 1997 Broken Records and Marjorie Music Publ. (BMI), - written and performed by Loose Bruce Kerr of the Dr. Demento Show and Sun Microsystems attorney. - Based on the WWI popular song, "Ja-da." Ukelele style on the recording taught to Bruce by his dad. - Re-produced with kind permission from "Loose" Bruce Kerr - http://loosebrucekerr.libsyn.com http://www.youtube.com/watch?v=TAX0gJt-aZg

  • Closing - Juan Carlos Jimenez - In the House (Intro No. 1)

  • To contact us:

  • Visit our homepage - http://javaposse.com
  • Post on our Google Group - http://groups.google.com/group/javaposse
  • Pose a question on our Google Moderator group - http://tinyurl.com/q4javaposse
  • Call us with questions and feedback - (408) 465-4626
  • Or send us email - javaposse@gmail.com

The Java Posse consists of Tor Norbye, Carl Quinn, Joe Nuxoll and Dick Wall

See All 476 Episodes of "The Java Posse"