I'd like to describe a work flow that I've come to love: Ping Pong Pair Programming.

Photo "Ping (Pong)" by Dustin Baxter. License: CC BY-NC-SA 2.0

What is it?

It's a combination of TDD (test driven development) and pair programming. Two people work close together on a task by writing unit test first and changing driver seat (at the keyboard) often.

How does it work?

  1. Person A writes a failing test (red).
  2. Person B:

    • Writes code that makes the test pass (green).
    • Refactor.
    • Writes a failing test (red).
  3. Person A:

    • Writes code that makes the test pass (green).
    • Refactor.
    • Writes a failing test (red).
  4. Goto 2.

It's fun but it is exhausting. Take frequent breaks!

As a reminder, here's Uncle Bob's Three Rules of TDD:

  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Why I like it

  • It is fun!
  • I like to program cooperatively
  • I think it is a good way to share knowledge and techniques.
  • By taking turns to write a failing test, the work is gamified.
  • Ha, lets see if you can make this pass!
  • Hmmm... Yea, that was easy!
  • High five! Next test...

When?

Ping Pong Pair Programming is, according to me, a very good way to work cooperatively on an assignment, producing high quality production code. Because:

  • The end result is better when there are two minds discussing and coming up with a solution.
  • And there is continuous knowledge transfer of the solution itself - now there are at least two people that knows about it which lessens the risk of the Bus factor.

In a whole group

A slightly modified work flow is suitable when in a workshop/exercise group setting. Ping Pong Group Programming! The first time I experienced ping pong in a group was at a Pluralsight Studygroup in Örebro, Sweden, organized by Christoffer Lette. We had been watching an Angular course and the last meetup we where only five or six people attending. We implemented the controller of an Angular Todo app by all of us taking turns at writing a failing test and then making it pass. Even though we did not know each other that well, it worked out great. The atmosphere was helpful and we had a lot of fun.

I decided to try it myself so I organized a coding dojo on unit testing with Jasmine together with my colleagues. We were a group of five developers that sat together during two lunch breaks, two hours total. I came up with a small task that we were to implement in JavaScript by doing TDD with Jasmine. It was a success so I did another one...

Next time we implemented Game of Life in .Net by ping pong group programming. We only did the logic but I had prepared the graphics beforehand, so when we where done with the logic we plugged it in to see the graphical result. I even prepared a button for inserting a Gosper Glider Gun for that extra wow effect.

Gosper Glider Gun

By Kieff (Own work) [GFDL or CC-BY-SA-3.0], via Wikimedia Commons

Most recently we did Roy Osherove's String Calculator TDD Kata. I picked it because you can stop where ever you like and still feel quite satisfied (not like implementing Game of Life where you have to complete it to get your reward - moving pixels) and because I did not know how far we would get since we had several new members in the team. I think we stopped after step four.

Rules when done in a group

  1. One person writes a failing unit test.
  2. Another person writes as little code as possible to make the test pass.
  3. Another person writes a failing unit test. And so on...
  4. Any one can refactor any code when needed but only when the tests pass.
  5. When the driver asks for help, the rest of the group politely helps out. The spectators must not shout comments and suggestions at the driver! Be kind to each other, it can be sweaty in the hot seat. Let the driver think, don't interrupt. Especially important in a group that does not know each other that well or the first time you try it in a group that already know each other.

When you write a new failing test, you are deciding on what new feature to implement. Be sure to think it through and pick a small piece. When in a group setting, it is important to try and switch driver often. Otherwise the spectators will be bored. I've also tried having a time limit like "we switch every five minutes no matter what", but that destroyed the continuity. We ended up changing each others half baked code which slowed us down. It is better to let each person finish what he/she started.

My advise

You've decided to try and organize a Ping Pong Group Programming exercise (Yay!).

  • Pick a small task that seems fun to work on. Could be something not related to your day job.
  • Solve it yourself with strict TDD. This way you will have some pointers and advice if the group gets stuck. This does not mean you can't participate in the exercise later, but bear in mind that the group can head in a completely different direction for a solution than you did.
  • Thoroughly explain the rules. Number 5. is important!

Comment please!

Do you have a question? - Comment below.

Have you ever tried ping poing programming? - Share your experience below.


I've also posted this on the blog of my employer, e-man: here.


58 0 0