A term so well-known among the software development community. Some swear by it, some hate it. Nonetheless, most of the developers tried it at some point. Pair programming brings benefits to some, but also trepidations to others.
It is something software development companies try to do when they encounter a complex task or want more experienced developers to transfer knowledge and guidance. It may seem like a pretty straightforward process, but if not executed properly, it’s counterproductive.
A quick reminder on what pair programming is
Pair programming is an agile software development technique where two developers work at the same station, meaning on the same computer with one keyboard and mouse. They work together on designing, coding, and testing while solving a specific problem.
It’s a joint effort between two developers who rely on each other and have great communication skills. Pair programming requires them to work in close collaboration, to write the code, and also discuss it and test it.
Although it may seem like a straightforward approach, it is not for everybody. It requires both hard and soft skills for developers to be on the same page throughout the whole process.
In pair programming, the two roles developers fill are the driver and the navigator. These roles have to be switched at every time interval those developers have decided on. The driver is responsible for writing the code. She or he is the person behind the keyboard. The navigator is responsible for the direction of the development. The navigator reviews the code, gives directions, and reviews the code.
How does it exactly work?
It seems a bit redundant to have two developers working on the same station. Many argue that you only fully utilize one of them, and you don’t need two to achieve the same results.
Well, that’s why these roles need to be clearly defined and their work scope should be complimentary, rather than one person doing most of the work. Cohesion is key.
Great organization among these developers is important. The roles are either assigned or they work it out themselves, as well as how will they approach the problem or task at hand. They start with receiving the task and deciding on small goals to tackle, one at a time. The process requires them to collectively agree on the best approach and technique. Switching roles means that the code will be of higher quality and done with more consideration. This is done in turn until the task is solved. Pair programming is based on the four-eyes principle, meaning more people see the problem from all sides, and must be reviewed by at least two people to make final decisions.
One important thing to remember is that pair programming is meant to be knowledge and experience-sharing occurrences to combat knowledge silos and towers of knowledge. Also, pair programming is highly oriented toward creating focused time slots where the driver and navigator remove distractions so they can effectively maximize their efforts and have a smooth workflow.
Let’s talk about pair programming styles
Pair programming can be done in more than one way. It depends on the experience and knowledge of these developers, as well as on their previous familiarity with pair programming.
As described above, this style is one where there is a driver-navigator relationship – one developer writes the code and the other directs and reviews the direction where it’s going. This style is based on active participation and both developers regularly switch roles to emphasize code quality and knowledge sharing. This style is good for partnering up a more experienced developer with one that is less experienced.
But note that in this case, you should not always pair someone who differs so much in experience and knowledge. This is not a mentorship program. Why? Because it beats the purpose of pair programming and it will take more time and effort to resolve a task. Also, the more experienced developer will most likely have to take on more responsibilities than the less experienced. If you do this pairing as an onboarding tool, do it, but don’t overuse it since it defies the role-switching aspect.
The unstructured style is just that, unstructured. There are no clear guidelines on how should one behave in this setup. Everything is organized and discussed as work happens, not before. The role-switching happens when needed and how developers agree on the go. This style could work with developers who have already worked together, have a great natural flow, and are similar in terms of their knowledge and experience.
This style is related to and matched with test-driven development. In this case, one person writes the test and the other writes the code to make the test pass. The pair should switch roles in writing tests and making them pass. This approach is great for moving the workflow and the complete development cycle.
Common pitfalls of pair programming
Even a popular technique, that derives from first programming works and cooperation, has some downsides. When you have people working together, you can always encounter some problems or even tension. Even the best relationships can suffer from some minor disagreements. But it’s not only that. Some outline issues with the business and profitability side.
Efficiency and cost
Some may argue that when you put two developers on the same task, you are losing potential gains if one of them could be working on another project. Also, pair programming takes more time to accomplish results. With continuous role switching it will take developers more time to get their head in and focus on their current role. Productivity is not as high as it can be if two developers work separately.
Issues with equal contribution
If you pair up two developers that differ so much in their skill sets, one might do more work than the other. More experienced developers will take on more and overtake the development process just to finish the task. This leads to no knowledge sharing which is a part of the benefit and purpose of pair programming.
As mentioned with efficiency issues, pair programming takes more time than an individual tackling the task. Just because developers switch so much going back and forth from driver to navigator, time is sometimes lost. Pairs thus work slower and spend more time on discussion and agreeing on the best approach rather than writing the code. It also takes more time for them to find cohesion and get in the groove of it.
Context switching and interruptions
Switching from being the driver to navigator means the developer switches context many times throughout the day. It’s harder to focus on their role when the switching happens every fifteen minutes or so. When they do manage to focus and catch their stride, they get distracted and interrupted by meetings and other pressing issues we all face daily.
Intensity in relationship
Be careful how you match up pairs. We already mentioned that there needs to be cohesion and understanding among the pair. But when you have people spending all eight hours sitting in close proximity and working in intense setups, tensions might arise. This puts a strain on the relationship and could cause issues in the long run.
Difference in skills and knowledge levels
When you pair up developers who have different levels of experience and skills, it will be noticeable. One will probably have to do more and teach the other developer how to work. This is fine if it’s short-term, but it’s not optimal to always put the more experienced developer in a pair with someone who is just starting or learning a new technology.
There is also worry in different personalities. One developer could be more controlling and will start micromanaging the other. Pair programming isn’t successful if one developer dictates how the other should work, write the code, review, and such. Roles should be equal and potentiate mutual respect and collaboration, and not a one-sided relationship.
But, pair programming could be extremely beneficial
Not all is bad in pair programming. As a matter of fact, many advocate it. It fosters collaboration and knowledge sharing which in turn dissipates knowledge silos.
Keeps you focused
If the pair properly organizes the whole process and agrees on time intervals they stick to, it will help them keep their focus on the task at hand. Because there are two of them, they will push each other to keep going and stimulate progress. The aforementioned time intervals when they switch roles, help them stick to the schedule and development steps.
Let’s you review the code as you go along
Because one developer writes the code and the other follows and reviews it, it helps prevent mistakes and bugs on the go. The sole fact that there are two sets of eyes on the code, means that it will be easier to spot mistakes and possible issues.
We cannot stress enough how much pair programming makes knowledge transfer easier. Two developers complement each other in terms of knowledge sharing and can fill in the gaps if someone is not as skilled.
Code ownership is shared
There is no sole ownership of the code if more than one developer is working on it. So, in cases where someone is transferred from the project, others can easily follow the code and documentation since there is more than one person who is familiar with it. The “bus factor” can be solved in this case.
Better code quality
It might be time-consuming, but in the end pair programming really does produce better-quality code. When more people work on it, someone will always advise on how to improve it and do it better. With fewer bugs, this definitely enhances code quality.
Pair up, or not
The verdict on pair programming is that there is no verdict. Some may say it’s the greatest thing ever, some may say it’s not. It depends on the situation and the individuals you want to pair. Not everyone likes working with someone. Interpersonal relationships do matter and could cause the pair programming to be either a success or a disaster. Developers are sort of forced to work together for long periods, and it’s hard staying levelheaded in such proximity.
Pair programming should be done only if the developers are willing to participate in it. It’s best to pair someone who already has experience in this, so they can help keep the structure and organization on point. It’s not a light decision to do it, but it’s definitely something worth exploring on your next project.