Pair programming: The technique in which two programmers share a single workstation.
What is Pair Programming?
It is a technique in which two programmers work in just one machine. The one who writes the code is called driver, and the one who reviews what is written is called navigator. In addition, the navigator also has to come up with a strategy to tackle the problem, making suggestions for improvements or prevent future problems. By doing that, the driver can focus exclusively on solving the task and rely on their partner for guidance.
Do not expect people to be good at pair programming from the beginning, it is a social skill that needs time to master. It is a cooperative way of work that needs efforts from both partners regardless of the corporate level. Both members should verbalize their thought process to become effective. This technique relies on successful communication over programming skills.
Swapping roles
This is a turn-taking technique, the programmers must switch roles often. How often do they have to switch, is something that every pair must decide, but in any case here are some known tactics:
- Ping-pong, used with TDD, one person writes a test and the other make it pass. Later they can decide if they do a refactor or write the next test, following a red-green-refactor structure. They must swap who is writing tests and who is writing production code, that is an anti-pattern of the technique.
- Pomodoro, members switch roles in every iteration of this method. It is more structured, but they have the time fixed to switch and mandatory breaks, something important and usually forgotten.
- Unstructured switching, when the members know each other well, they can decide when they pass the keyboard to their partner. The only concern here is that at the end of the day, they must have been in both roles the same amount of time.
Benefits of pair programming
It seems like an ineffective use of resources, the literacy and empirical studies say that two programmers working together have at least nearly the same productivity than working separated, some others go even further than that,... I guess it really depends on each team.
The amount of errors is reduced considerably, therefore the software quality is increased without compromising the time to deliver. This increase in quality will pay off later in the project. At the beginning, the productivity may decrease a bit, but it is mainly because the quality of the code code produced is much better.
Solutions are evaluated upfront, not once they have been implemented in a code review. Before implementing a solution, the pair discuss, evaluate and identifies the possible trade-offs.
It is an effective way to share context and knowledge of the project across the development team, when the code is written, both programmers share the context. The knowledge and the context is spread across the team, so when somebody leaves the project, it is not that dramatic and the team does not need to spend extra time in meetings or code reviews.
One of the biggest advantages of pair programming is the mutual learning. The best practices are shared, it is the best way to develop skills, especially for junior programmers, but it has its benefits for senior programmers too. Everybody has something to teach, everybody has something to learn.
The positivity in the team is increased, facing complex problems with someone helps the moral support of the individuals.
Procrastination is reduced to the minimum, knowing that having someone waiting for you to work puts some pressure. Also distractions are reduced, because most of the times you cannot respond that slack message or that email in front of the other person.
Pair programming also makes awesome on-boardings, the productivity of new members of the teams is boosted when pairing with more experienced developers.
Increases overall employee satisfaction, developers are not just happy because they are learning a lot from others or because they are improving their career. They also know better their peers at personal level, which builds a feeling of belonging to a community or a pack. This is great for introverted programmers, which are the majority of them.
It helps to develop interpersonal skills, teams become more collaborative. They learn how to communicate with each other, work together, organize themselves and share information.
It is a fantastic recruitment tool, doing an exercise or a kata using this technique you quickly realize how the other person analyzes the problem, how approaches it, if the feedback is accepted, and how is the code produced. Sure there are other factors to take into account in the recruitment process, but generally, people don’t code at the same level that they talk, some are above and some others below.
Concerns to take into account
It is difficult to engage developers that are free in the wild to commit to work with someone. This technique may not be attractive at all to developers that always have worked on their own.
Despite the fact that there are some companies that do not allow to write production code alone, it is not a good option to force its adoption, members of the team may have issues between them and forcing them to work together could lead to dramatic consequences.
Beware of stress, fatigue and motivation, when programmers are not in the proper state, they may not be concentrated or communicative enough to perform a good pairing exercise, dropping the productivity of the pair.
Simple tasks may be ineffective due to its simplicity. Two heads think better than one, on complex tasks for sure, but in simple tasks where there is no need to anticipate possible problems and the code is so simple than does not even need much attention, the navigator may get bored and out of the exercise.
Conclusion
This is one of the core techniques of the extreme programming practices, it should be at least considered by teams and organisations.
Take into account, that theoretically this may look costly ineffective in the short term, but the increment of quality pays off in the mid-long term.
Personally I think that the risks or problems are not that complicated to prevent and the benefits that you may get are so interesting that it would be a big loss not give it at least a try. It doesn’t need to be fully adopted by the organisation, nor do it all the time, but enough to learn it and to be sure that it is done right, measure it and make a decision based on the results of your team. Remember, pair programming is not for everyone.
Top comments (0)