Pair Programming Needs to Be Extreme
Since its introduction, pair programming has been a highly polarising concept within the software engineering community — a quick google search yields dozens of posts that discuss its merits, problems, or try to juxtapose both.
As I scoured through them in preparation to write yet another one, it struck me.
Majority of the articles dedicated to pairing discuss the matter in isolation, but the practice didn’t come into the spotlight all by itself… It gained traction as part of Extreme Programming and once I began analysing how relevant that connection is, it all started to add up.
Extreme Programming relies on strong foundations to function properly and these have taken the form of its five values:
- communication,
- simplicity,
- feedback,
- courage,
- respect.
The Boclips product team embraces those and pairing “just works” for us, which leads me to think the practice will have a hard time if that mindset is not shared between members.
Let’s see how XP values tackle some of the most common concerns people have towards pair programming.
Working in pairs undermines creativity
The argument I’ve seen here is that developers working in pairs are less likely to experiment with more controversial approaches in fear of wasting the other person’s time if the idea doesn’t work out.
Out of the blue, this is a valid and reasonable point. If a piece of work is uncertain, why risk binning twice the time spent on testing it out? XP’s answer to this scenario is courage.
Experimenting as a pair brings a bunch of benefits to the table — for once, the experiment can be conducted quicker thanks to the tight feedback loop maintained between both engineers. At the same time, it can be halted earlier if either person spots that the whole thing is not going in the right direction. Developers shouldn’t be afraid to throw code away, because in the worst case it was a lesson learned (and shared between at least two people).
Also, let’s not forget that the feedback loop that speeds up verification can at the same time give creativity a boost and lead to even better ideas!
That said, while we believe that pairing creates a safe and efficient environment for exploring different ideas, we totally respect that some people like to take a bit of private time to quietly chew on a problem and do some digging of their own. Programming in pairs can be exhausting and everyone needs a break every now and then.
Pairs of unequal skill cause frustration
Some people mentioned problems that can surface when there is a considerable difference in experience within a pair, with a senior+junior combination being the usual example.
The scenario to look at is a seasoned developer who eventually gets fed up with having to explain everything to the junior and not being able to work at their usual pace.
But given such a setup it’s no surprise that one engineer will be learning from the other. What matters here is the attitude that both sides have towards such pairing sessions and XP values help to foster environments that support a healthy attitude.
At Boclips we know that everyone should be treated with respect. We’ve all been junior at some points of our lives and we keep that in mind — taking extra time and patience to share knowledge always pays off in the long run. It can be a valuable experience for the mentor as well, since questions asked by the junior can challenge their long-established view and lead to improved or simpler solutions.
Juniors end up “watching the master”
This is closely related to the previous example — we have a less experienced colleague who feels anxious about not following so quickly and eventually withdraws themself, letting more adept person do all the work.
Communication is key when working in pairs. Without it, pairing is merely a fulfillment of management nightmares where two people are assigned to tasks that could’ve been completed by one. Both developers should aim to keep the conversation going in order to exchange ideas and cross-check the common understanding of the solution they’re working on.
In setups where one person has more experience, this sets a degree of responsibility on the senior one to ask for feedback from their pair. “Is what we’ve done clear to you?”. “Would you like to drive for a bit to better understand this?“. “Shall we take a coffee break and clear our minds?”. Any of the above will be appreciated and help with checking the pulse.
Pair programming leads to code dis-ownership
Another con I’ve seen being mentioned was that since engineers deliver code in pairs, in the end none of them feels responsible for it if something goes wrong.
The other side of this coin is that people who pair program too often grow reluctant to committing code on their own, in worry that they’ll miss something important or introduce a bug without another pair of eyes verifying the change set.
It takes courage to admit to an error and take responsibility for it. We respect that everyone can make a mistake and embracing a no blame culture is something very important for us at Boclips — it bolsters proactivity, keeps morale high and enables learning.
Additionally, while we often rotate our pairs in order to improve the communication flow between engineers, each story has a lead developer who’s accountable for getting it through up to production.
Pairing on simple tasks is overkill
Programming as a duo doesn’t come for free — there is an extra amount of communication and coordination required to keep it running efficiently. Sometimes it’s hard to justify this extra effort, particularly in scenarios when neither side is learning anything…
…and we Boclippers wholeheartedly agree with this!
We strive to maintain a pragmatic point view and keep things simple. If the task at hand is clearly understood by everyone and/or can be finished quickly, there’s no real need to kick off a pairing session. As much as we love working together, it’s perfectly fine to go solo when it makes sense.
Due to its reliance on a specific mindset to run smoothly, pair programming is not a silver bullet that works for everybody. While by itself this is no breaking news, I hope the missing part is now clearer to you.
The fact also explains why some organisations run into trouble when management “drops” it on the development team in hopes for a magical quality boost.
Have you ever been in that situation? Perhaps you find pairing appealing as well, but it didn’t work out among your folk? Take courage and check out our careers page if you’re still looking for the right crowd to give it a spin.
