What Is Pair Programming?
Although most of our readers probably know what this term signifies, let’s just quickly clarify it. Namely, we are talking about the agile software development technique which requires two programmers to work at one workstation.
In this setting, there are two roles: the driver and the navigator. The driver writes the code, while the navigator reviews it, provides feedback, and corrects small syntax mistakes right away. Remember – it is essential to have the teammates switch roles at least on an hourly bases, but preferably in a matter of minutes, so that they get enough rest.
Reputation and Acceptance
There’s an ongoing discussion on whether pairing up programmers to work on one task has more good or bad sides.
From one point of view, it improves quality, efficiency, and knowledge distribution. Yet, look at it from another angle and the emphasis will be on the waste of time, finances, and an individual’s creative ideas.
In cases like this, it is quite hard to reach a definitive decision on whether the upsides outweigh the downsides, or it’s vice versa. Eventually, it depends on the company, goals, personalities of the employees, etc. Hence, we will just list general for and against reasons for pair programming implementation, and you can decide how this arrangement would work for your team.
Pair Programming Upsides
First, let’s take a look at the several most prominent advantages of this work organisation.
#1 Reduced Dependency on the “Top Performer”
In some teams, there are these programmers who have detailed knowledge of the whole codebase. They are always the ones to whom other developers turn for help and clarification. We call them “top performers” or “towers of knowledge”.
There are numerous problems which can arise from this sort of knowledge disparity between the employees. For example, the top performer will constantly be bothered with different help requests as well as overwhelmed with workload since they would be the only ones who could handle some of the more complicated tasks. Moreover, dealing with various assignments further improves their capabilities, thus reaffirming their position as the company’s “tower of knowledge”.
These are the situations where the management should consider the so-called “bus factor”, i.e. what happens in the company if the top performer gets accidentally hit by a bus. How would the company get by without their deep knowledge of the codebase?
Here’s where pair programming comes into light. The manager can simply pair up the “tower of knowledge” with some of their colleagues. Thus, these co-operators will get more detailed information about the current projects. Additionally, they will be able to learn from the top performers, and over time, the information distribution within the company will become much better. Consequently, this will reduce the dependency of the whole team’s performance on only one member.
#2 Better Code Quality
Programmers spend a significant amount of time on tedious correction of minor bugs. Instead of doing the creative and challenging work of writing new code, they are stuck correcting the typos and sneaky mistakes in the one that’s already been written.
Programming in pairs reduces the occurrence of these mistakes by 15 per cent, according to the University of Utah. Eliminating a good deal of bugs instantly means a higher quality of the code’s first version, and thus less time reviewing it as well as lower maintenance cost later on.
Additionally, pair work also results in the assignees’ better concentration and more responsible behaviour. To put in bluntly – if you know someone’s always watching what you’re doing, you’ll make it your best work. This means less cutting corners and more invested effort.
It all amounts to a high-quality code with cheaper maintenance expenses.
#3 Improved Productivity
You may not be a programmer, but you must have found yourself in the following situation: you have a task that you don’t know how to solve. You start googling for a solution, but it just won’t reveal itself. Yet, you feel you’ve already bugged your superiors or co-workers enough and you don’t want to become an office nuisance. What do you do?
Well, in pair programming, the teammates have the chance to discuss possible solutions and get out of their solitary no-solution loop. With this work arrangement, no one – not even the introverts – will be afraid to ask for help. They won’t “over-ask” either, since they’d have each other to discuss ideas for possible solutions before asking another colleague for help. Thus, a significant amount of time is saved on unproductive digging for answers which further results in productivity boost.
#4 Quicker Inclusion of New Team Members
New hires are usually expected to go through training and introductory guides during the first month of their tenure. In this time, they suck out value from the company without being able to contribute.
However, pair them up with a seasoned developer, and they will instantly start learning and contributing. This method works better than the usual “training first” approach, and for more than one reason. Firstly, the newcomers usually don’t lack programming knowledge, they just need to be introduced to the company’s codebase. Pair work with an experienced employee will start this process from day one, while having them produce actual value for the employer. Secondly, the mature programmers in the role of a trainer will try their best to write a high-quality code instead of using shortcuts here and there. Hence, this arrangement leads to an easier and more productive onboarding process overall.
Pair Programming Downsides
Despite the mentioned benefits of pair programming, those who have had the chance to experience it also report significant setbacks of this method. Let’s have a look at the most prominent disadvantages.
#1 Complicating Simple Tasks
Fixing simple bugs or implementing uncomplicated features is not a job for two programmers. Not only is it a financial waste, but it also wastes their skills.
So, if you plan on implementing pair programming at your workplace, keep in mind that it is not appropriate for every single task. In other words, although it may be useful with complicated and tricky assignments, it may be equally counterproductive with technicalities and undemanding fixes.
#2 Questionable Sustainability
If there is something everyone agrees on, it’s that coding in pair is impossible to practice throughout the whole eight-hour workday. Anyone who has tried working in this setting, whether they are pro or against it, firmly states that programmers shouldn’t be forced to code in pair for more than 2 – 2.5 hours per day.
Even with this limited pair coding time, some programmers simply find it overwhelming, and finally, they will start searching for a position within another company that doesn’t require such a close and intense cooperation.
Additionally, there is also a feeling of being constantly supervised and scrutinised. Developers start feeling pressured by the “violent transparency” of their work, as one of them has put it. Consequently, they feel drained at the end of the day, both physically and mentally. And if this is what they go through on a daily bases, it’s clear why they eventually leave the organisation in search of a more relaxed work environment.
#3 Lack of Autonomy and Creative Outlet
Pressure and dissatisfaction aren’t only the results of the intense workflow, but also of the position of over-accountability.
Say one of the programmers has an idea how to do a common task in a different and innovative way. First, they must take time to explain to their teammate what they want to try and why they think it would work. This will significantly prolong the process. Also, the introverted member of the duo will shy away from even mentioning this new idea for fear of the whole process ending in failure. On the other hand, were they working alone, they would quickly try out the innovative approach, and if it failed, it wouldn’t matter since no one would know about their little miscalculation.
#4 Friction of Ego and Personality Mismatches
As with any profession, there is a lot of ego within programming teams. Naturally, people will defend the work they’ve done and the ideas they have regarding some solutions. However, sometimes their stubbornness and unwillingness to cooperate and compromise prevents the whole team from moving on with the assignment at hand. Developers are no exception, and if one member of your duo happens to have this personality type, the small team you have created will be almost completely dysfunctional.
Overblown ego isn’t the only personality trait that may get in the way of pair programming method application in your company. There are also those employees who just can’t help talking to the person they are paired up with. This is good for bonding of the teammates on the personal level, but it will make their productivity plummet. Then there’s arguing, matters of personal hygiene, etc. You get the point. So, make sure the employees you plan on pairing up see eye to eye on more than one thing. Otherwise, you’re in for a disastrous experiment.
The Final Word of Advice
Measure. This is the only notion to keep in mind when pondering pair programming implementation. Make sure you have an interesting and demanding task for your mini teams so that their time, skills, and company’s finances are put to best use. Also, remember to frequently mix up the teams so that the information distribution is equal between all employees. This will also help break up the dysfunctional duos, improve the team’s feeling of community, and make the inclusion of newcomers easier. Most importantly, cleverly dose the amount of time your developers spend working in pairs. We have mentioned that this work dynamics is extraordinarily tiring and frustrating. So, use it wisely and keep in mind the wellbeing of all team members, or else they will be forced to leave in search of a less stressful position.