Ping Pong Programming
Ping Pong Programming
Hi guys, in my last post I gave a small introduction to pair programming. This post will be short where I would like to present a small technique that can be used during pair programming. I learnt this in Rachel’s and Liz’s book - Ping Pong Programming. This technique ensures that both members of the pair take a turn at the keyboard. Below you can find the steps.
- The first developer writes a falling test and then passes the keyboard to his pair
- The second developer writes just enough code to make the test pass
- They then work together to re-factor the code that has just been written
- Then the cycle can start again with the second person writing a new failing test and handing the keyboard back to the first person.
What do you think about this approach? Do you think that would help your developers? Do you think it would Ping Pong Programming next week or on the next coding dojo at your company?
If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.
I would love to get a star rating for this post:
More from our blog
See all posts
Hi guys, this week I want to tell you something I have…
Hi guys, in this blog post I wanna explain a way to…
Hi guys, in this blog post I want to explain how to…
Interesting, In my developer life, at some point we did something very similar to get some fun doing pair programming: Each developer has X number of line to write down. After that, the other one, need to continue from there. Some time it was X minutes each one.
The idea was to avoid one hour looking the code of others.
I remember that the last 30 min of the pair programming session was “re-factoring” of the new code. It was a lot of fun.
Did you try something like that?
take care,
Omar
At the code retreat in Berlin we played this and it was a lot of fun.
We also played “mute with evil coder” which is a good way to learn how to write good tests that drive the code.
How does it work:
- Developers are not allowed to talk to each other and explain stuff they did. The code must speak for itself
- First developer writes a failing test case
- Second writes the absolute minimum code to make the test pass
- Because they are not allowed to talk the test writer has to explain his intention with his tests and try to drive the implementer to write code that will solve the problem with an algorithm instead of long if statements that handle each possible parameter value on its own and only cover the test cases.
A lot of nice ideas are collected here:
http://coderetreat.org/group/facilitators/forum/topics/what-are-some-exercises-and-constraints-that-people-use-during-se
Sorry, I did not notice this post right away and commented on the previous post. Yes, I have positive experience with this approach.