Whose Line of Code Is It Anyway?

This talk is a hands-on demo of Ping-Pong Pair Programming, a technique that combines TDD and pairing, in a fun way. The audience has some opportunities to participate, but the shy ones don’t need to. :-) If time allows, we will also demonstrate “Smart@$$” Ping-Pong Pair Programming.

You might know the game of ping-pong, aka table tennis. You might know pair programming. But have you ever thought of putting them together? No, we don’t pass the keyboard by smacking it with a paddle. It’s much less violent and more useful than that, as a technique to combine pairing and test-driven development in a fun way.

This talk will demonstrate Ping-Pong Pair Programming, with possibly some audience participation. (Don’t worry, you don’t have to.) If time allows, we will also demonstrate “Smart@$$” Ping-Pong Pair Programming, in which each dev tries to force the other into doing the actual hard work.

I am planning this as a regular breakout session, but if you want, I could turn it into a workshop.

This has been submitted to some conferences, but not yet accepted (nor rejected), let alone performed. I have several potential co-speakers, and even if none of them are available, I could use a volunteer from the audience, or maybe multiple of them.

Prior knowledge needed: only basic concepts of unit testing, as I will explain TDD and pairing (and ping-pong). Though there are a variety of languages the demo could be done in, all are fairly English-like and should be reasonably understandable to all devs.

Ideally this has two speakers (other one TBD), but I can alternately take a volunteer from the audience, or a series of them.

The idea is language-agnostic, and I can do it in several languages – if your conf is centered around one I already know, maybe I can learn it (and its testing tools) enough to pair up with someone who knows it, and still do the talk at your conf. :-)

The rough outline so far:

• Very briefly recap what are ping-pong, pair programming (mentioning test-driven development), and TDD.

• Ask the audience what language they want us to work in, from among those (up to four or so) that my co-speaker and I have in common. (Or if I couldn’t recruit a co-speaker, just those I’m ready to do.)

• Ask the audience which of a few different fairly simple functions to code up using this technique, or maybe additional suggestions. Candidates so far include “FizzBuzz response for one number” and “next state of a cell in Conway’s Game of Life, given its current state and number of neighbors”. We may do multiple if time allows.

• DO IT!

• Recap good/bad parts of that experience.

• If time allows, demonstrate “Smart@$$” Ping-Pong Pair Programming, in which each dev tries to make the other do the “real work”, by writing a test that can only be made to pass that way, while also trying to avoid doing the “real work” by writing code that passes all tests so far BUT is even simpler.