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.
- Make the team members that always disagree try to build up on top of the ideas already presented.
- Some members of your team are very stubborn and you want to show them that there could be other solutions than their own.
- You want to improve solutions immediately when you see a smaller or larger improvement option.
- You want beginners to feel they add value when pairing with more experienced people.
When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.
Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…
So the rules are:
- none of the pairs can delete the code of the other.
- at each step when switching from driver to navigator one needs to improve the existing solution and tests.
- whenever one of the pairs tries to delete the code, the other needs to say “You should improve the existing one. Please go back and say Yes, and… I will do…“.
- none of the pairs are not allowed to be angry on this request of not deleting code.
- only unused code can be deleted, like for example after refactoring the code is not used any more. Both of the pairs must agree that the code can be deleted.
Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.
Your team will have a more productive collaboration. This will happen because they will all try to avoid deleting existing code and they will rather try to improve through refactoring the code that is not that good.
The code will be considered as the product of the team, and not the product of a person. This means that anyone in the team will be comfortable to change any part of the code.
Your view as programmer changes from “my best solution” to “this is one of the possible solutions” and you might even have a dialogue with yourself with the purpose to improve your own code. Or you can do teddy-bear pair-programming with “Yes, and…”. So your mind will be more opened to alternative solutions. I consider that having more solutions in mind is a very important aspect of the way programmers think in an effective way. Of course choosing a good solution is not always easy, but thinking that there are more solutions out there is a must for me.
The team will communicate more and get a common understanding of their knowledge and technical values. But you need to make sure all the team members pair with each other for a sufficient number of times so the values will emerge.
During this dialogue between the pairs maybe the facilitator might need to make explicit some common sense rules of dialogue: do not talk for too long, do not interrupt the other, keep your idea focused to the point we are discussing, and maybe others.
They will be more open to change. You just need to add change on top of the existing system and not as redoing part of it. Think incrementally.
Make sure your first couple of sessions of this type are supervised by a coach. When starting you need to explain very well the purpose and the rules of the game.
Repetition is the mother of learning, so you should try and repeat this game a couple of times. With some teams you might need to deal with their rejection, but it is part of the job to convince them.
In my view this game is very effective in the process for implementing the idea of collective code ownership. It might not be a good idea to start with this, but it could be useful in the process.
Sometimes I present this game during coderetreats as a constraint for one of the sessions. It is a very different constraint than ones you usually find, because it is focused on communication and soft skills rather than on programming skills.
During the years I found it is very useful to push it more when I see coderetreat pairs or teams not collaborating to get a good result together, but rather arguing and losing time and energy useless.
I first came across this idea on Abby Fichtner’s blog about pair-programming games, a couple of years ago. Since then I tried to improve the concept and use it for more purposes than I initially thought.
When will you try to improve the code rather than rewrite it?
Image credit: http://www.flickr.com/photos/visualpunch/7245661414/