Don't Abuse Pair-Programming

One excellent thing that comes with the agile methodologies is the set of practices and ceremonies it has popularised if not standardised. Those practices have all one common prime goal: “to heal the divide between business and development“¹. It is a good thing to meditate as we could easily believe the main goal in Agile is code quality or developer empowerment. Hell no, it is about trust. Tell me how much your stakeholders trust you, I’ll tell you how agile you are.

How does pair-programming create trust? Well, I guess at first sight it doesn’t. At first sight it doubles the cost. That is not the best way to build trust. But trust is not something you make out of nothing, it’s a chain, it’s a web. For the business to trust the delivery team, the team has to trust itself, its processes, its skills, its tools and technologies and last but not least its solutions. Pair-programming addresses those concerns. Like everything in our professional life of engineers, it is a trade-off: engineering resources vs trust in the engineering. By pair-programming, we trust more our code. Each line is double-checked, each decision is debated. The whole codebase is more consistent and well understood back-to-back by the entire team.

Mind you, this doesn’t double the cost, far from it actually. Brains are like threads and even if Amdahl’s law applies, you still get a significant boost in productivity by having a pool of 2 vs 1. For me, the biggest benefit happens on debugging and focusing. Debugging requires challenging assumptions, looking at the issue from different angles. That parallelises well. Keeping focus while coding can be a challenge; I know it is the case for me. First it is intense for the brain. Mine tends to stay away from any prolonged effort… Second, coding often implies learning. Wikipedia, Stackoverflow, GitHub are good friends …as well as terrible distractions! Third, the process of coding is utterly preemptible with lots of IO: run that test, compile that code, deploy that project, restart that thing. The brain keeps going from 100% utilisation to 0%². Hardcore. The pair is impressively efficient at keeping the task on track.

Therefore pair-programming drives trust by increasing quality and improving focus. But it has its downsides. To name a few:

• it is awful for deep learning³. Imagine you joining a project that’s well off the ground and uses a build tool, a test framework, a back-end and a front-end technology that you don’t know. And your only chance to contribute to this project is by pairing 100% of your time with someone who already masters all this stack. Well you’re screwed. You’re the John Snow of that story and sprint after sprint, Ygritte looks upon you with such disdain and repeats: “You know nothing, John Snow”. Now opt for a 50% pairing time only and for the rest, struggle on your own: I’ll bet in 2 weeks you’ll have caught up with the learning curve. At times, you’ll even teach new tricks to your teammates. It’s a big deal.
• it prevents true creativity: it is already a committee, as such poor at thinking out-of-the-box.
• it is tiring: my brain constantly adjusts it’s pace to the one of my peer’s brain. At the end of the day, my synapses bleed.
• it limits the dev environment. I know what I am talking about I am using an over-tweaked Emacs and a French Dvorak keyboard layout. It takes my productivity to an other level but it’s far from being pair-friendly.
• if a team member tends to not pull out his/her weight, the pair mode will make it harder to identify and deal with.
• it sometimes just doesn’t work for some individuals. The way we learn, the way we think, the way we look at things, it’s always different right? That’s the whole point of pair-programming after all: make a difference with our differences. But if pairing is not your way to enrich the team, that’s just fine my friend. That doesn’t mean agile isn’t for you, don’t let anyone tell you such non-sense. You just need to dig deeper and find your way in this quest towards great trust within the team and beyond. Know thyself⁴ and invent.

All I am saying here is that if you’re pairing 100% of the time, you’re doing it wrong. It’s a wonderful practice but it comes with trade-offs. It’s no silver bullet, so don’t be a fundamentalist and acknowledge it is Individuals over Processes.

In other news, winter is coming.