Silent Programming
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.
Purposes:
- 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
Concept
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.
Outcomes
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.
Remarks
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
Very cool!
Did you try this in dojos or while writing production code or both?
Yes, I often explain and facilitate this concept during a lot of community or in-house session types.
We tried this in our in-house code-retreat. It was the last session and Adrian introduced it as a relaxing session together with “evil code”. I really enjoyed the mute pairing part. There is a thrill writing a test and waiting how your pair will resolve it, or respond to one of his tests with a simple code fix, taking advantage of the gaps in his test. I am already looking for the next chance.