Blog post series
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
- Useful when you have talkative people in your team that do not agree or agree but do not write enough code for one task.
- The code is not easy to read
The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.
The programmers get things done faster.
The quality of the code increases, especially the names used for variables, methods, functions, classes, etc because code is their only way of communication.
The names of the tests become very easy to understand for anyone.
More refactoring happens from both of the programmers, just because the code is they only way to communicate.
From what I saw during this game, programmers are having a lot of fun when doing this game.
It should not last very long.
It should be repeated from time to time to stress the intent and to see improvements in the team from the last session.
The facilitator, if any, needs to make sure the pairs are respecting the rules at any time. The facilitator, if any, needs not to accept any deviation from the rules.
Some programmers might be frustrated because they cannot communicate verbally. This is an exercise to communicate through code and it should be taken as one learning experience.
In some rare cases the two programmers will not get allong and refactor the code without adding meaning to it and without understanding what each other is doing. This is a risk of the game, but it shows in the same time the collaboration ability of the two persons.
When will you try this game?
Image credit: http://farm3.staticflickr.com/2332/2306206890_2596ebc13d_o.jpg