Pair programming is an Agile software development technique that was popularized in the 1990s by the Extreme Programming methodology. One of its rules is that each work item performed must go through the hands of at least two team members.
As a reflex, we might think that the code review process is the ideal way to ensure compliance with this rule, but it is a risky practice because some team members can vigorously express their views. People who are used to working alone can then be unintentionally insulted or destabilized. We then find ourselves with colleagues who are afraid to make decisions because they fear seeing them crushed.
Sometimes, contextualization can also be complex and arduous, or there might even simply be no clear and definite consensus on the method that will be used to achieve our ends. We must talk to each other! This is a sign that a pair programming session would be necessary.
Before you start
It is important to target work items beforehand so as not to waste time doing repetitive tasks together. When planning with the team, we can already ask ourselves if the items have:
- A high level of uncertainty about which we can exchange.
- The need for a design, such as mock-ups or creating a central element of the application.
- Someone on the team who has an interest in the subject and wants to learn more, or demonstrate it.
Sometimes, it can also be a bad idea to start a pair programming session, especially if the interest is not there. The discussion must remain positive and the communication open. If one or the other feels forced, do not hesitate to postpone.
It is also important to define the scope of the task before starting in order to have a goal achievable in 1.5 to 2 hours. If the session is too long, we will lose our concentration and feel that it is useless.
Different Pair Programming techniques
To fully understand how each technique works, it is important to discern both roles in a pair programming session. The person who has control of the keyboard is the driver and the teammate who follows the production is the navigator. Note the vocabulary used, a navigator is not a spectator, but someone who will help the driver navigate through the stages!
- Each our machine
The driver uses his computer to do the work in the application’s code while the navigator can have the freedom to use his own to do research that will help the orientation, or to produce mock-ups that will allow to choose the best solution.
We must pay attention to the loss of concentration if, for example, one of the two takes time to go on social networks for a few minutes.
- One machine, two keyboards, two mice
With a small investment, a pair programming station can improve focus while speeding up the transition of taking care of the keyboard. Usually, this type of layout needs to be isolated to prevent discussions from disturbing the rest of the environment, which may need silence to focus.
- Ping Pong Pairing
By practising test-driven development, the navigator can take care of writing the tests so that the driver can later develop the feature that will make this test go green (it runs successfully).
Unit testing can be used by the navigator to communicate his vision of the code, while end-to-end testing, or user interface testing, can already set up an automated quality assurance process while giving the possibility of taking screenshots.
- The Analyst
The navigator plays the analyst role. He does not have access to the keyboard and uses paper and pencil to reflect in detail on the current development. He follows the code the driver is creating and does not hesitate to suggest improvements and review what has been done so far. This technique is particularly interesting when there is a portion of the work that touches the design (software, architectural or user interfaces).
The traps
- Get out of your comfort zone
Avoid moving away from the least interesting tasks. By being versatile as much as possible, we can take advantage of pair programming sessions to challenge ourselves, to ask the right questions and to find the best way to apprehend what we have to achieve.
Keeping this golden rule in mind, pair programming helps to avoid procrastination by allowing us to have fun even if the task at hand is not always interesting.
- Do not overwork yourself
Keep the duration of the session limited, between 90 minutes and two hours, and then return to individual work. When you are tired, it is time to stop. It is often because of fatigue and stress that communication is not so good. The impact on quality is direct; more and more problems are occurring in the code and quarrels may break out.
Small breaks here and there may also allow us to clarify our minds before continuing. This aspect should not be taken lightly; it is often near the coffee machine that discussions are the most interesting.
- Take small steps
Let it be said and repeated, to move forward, we need small goals; or even micro-goals! Everyone must support their teammate and collaborate with them at all times. If you are stuck, you can easily change course and move to a more defined feature and then back to the one that has been set aside.
You do not know what to do when you are the navigator?
Focus on the code review. Your attention should be total, so that nothing escapes you. Think about possible bugs, bigger problems, or ways to improve and simplify the design of the application. If you do not understand the work the driver is currently doing, it is your role to make sure you know enough to be able to do the review.
Be careful not to lose sight of the fixed micro-goal! Feel free to take notes and wait until the end to raise errors or ideas for improvement.
And above all, do not distract the driver…
- Take a moment to celebrate when you complete something
Do not hesitate to do a high five or take a five-minute break. You have worked hard and you deserve it. By making sure you maintain this collaborative spirit, you will combine your energies and achieve exceptional results. If you lose this momentum, you will quickly feel like you are working in parallel and you will probably both prefer to work alone to move faster.
Collaboration is worth promoting
Working with someone allows us to positively face the different problems we encounter. In addition to quality that is obviously impacted by the continuous reviewing, the benefits are numerous:
- It is difficult to procrastinate, we do what needs to be done together, interesting or not.
- Good practices are shared, the navigator can afford to research while the driver is coding.
- The increase in knowledge is faster because new employees collaborate with older ones.
- Allows quick identification of a candidate’s profile by pair programming during the interview.
- There is an increase in employee satisfaction, caused by the fact that everyone can speak their mind, even employees working remotely.
Nevertheless, some people find that it is not an optimal use of their time. That is why pair programming sessions should only happen when we feel the need and not when planned. Usually, the entire team ends up attending sessions one day or another, even if it is not required.
There is nothing better than a Friday afternoon with a festive atmosphere to encourage people to collaborate on everything and anything. Some will take advantage to spend a moment on conception, others can bring new product ideas.
On the long run, you will have improved productivity, positivism facing challenges to overcome and a product of unquestionable quality.
