Pair Programming is very cool, and at some point you start to get addicted to this practice, kind of a 12-step program. In an early stage, it is usually difficult to have a with a good pace of work. However, in the next phase, the team start to realize that something like “this is amazing”; and from now on, the team only wants to work in a Pair Programming mode. Finally you end up realizing that there have to be a balance, in example: is good to maybe have 2 sessions of Pair Programming in a day, one in the morning and another in the afternoon. This gives time so then everyone in the team can have its own time for research, personal development time and play some online game.
A classic bad example of Pair Programming is when an Alpha developer and a Beta developer, are starting to work together. That’s it without have some clear rules. The Alpha programmer, as we all know is often very dominant. The Alpha Devs, impose his point of view, etc. (kind of a Punisher in dev mode). In a model of Pair Programming, this programmer has just taking over the control in the keyboard, writing all code, and refuting any suggestions or criticism received from the Beta dev. In the toher side, the Beta developer is more comfortable in a position where not falls on him (or her) much responsibility, so this living in this 2nd level is fine.
A solution for this type of scenario, is to work in Pair Programming, with a model “transmitter” and “receiver” (or “leader” and “key presser”). In this model, you can work in small time lapses, ie: 25 minutes (the Pomodoro Technique) During this period of time, one of the developers will be responsible for coding and the other will be the one which tell what to do.
The “key presser” can not directly code based on what he thinks, but it must be the hands and fingers of the ‘leader’. This model is incredibly unproductive at first, however when it passes a time has a number of advantages
- The fact of forcing that one code and the other leads, move to the team members improve their communication skills
- The leader has to learn a quick and consistent way to communicate his ideas so that key presser can carry them out
- The key presser, have to learn to listen (this seems obvious, however usually is very complicated)
- When the leader explains his idea out and loud, it tends to be a great time to detect problems, bugs, etc.
- On the other hand, the part listening also has voice and vote, can challenge an idea, collaborate with it, etc.
Depending on the size of the team, it is also important to do rotations in pairs that work. And not try to gather the most obvious profiles.
I encourage you to try this model and then tell me!
> Pair Programming, http://en.wikipedia.org/wiki/Pair_programming
> Punisher, http://en.wikipedia.org/wiki/Punisher
> Pomodoro Technique, http://en.wikipedia.org/wiki/Pomodoro_Technique
> Picture, http://avengersalliance.wikia.com/wiki/Punisher/Dialogues