Some highly opinionated and inflammatory thoughts on the practice of Pair Programming
Imagine you are in a three legged race. Imagine your partner is a foot taller than you and runs at an uneven pace that randomly jerks you forward then holds you back so you keep stumbling as you struggle to keep your balance. Now imagine that instead of having to make it across 100 meters at the local park you are running a marathon over steep hills and rushing rivers, through tangled forests and down murky, wet holes that expel you into oozing quagmires, all the while trying to deal with having one leg strapped to someone who is dragging you along at their pace so its twice as hard to get your bearings, never mind a foothold, in the treacherous terrain.
This is what pair programming feels like.
What follows is going to be a rant, a cogent rant but a rant nonetheless. It’s going to get a bit emotional and hopefully be therapeutic (at least for me). A lot of you will vehemently disagree. Many more of you (I suspect) will feel relieved that they are not the only ones who have silently suffered under pair programming’s tyranny. I look forward to both the pitchforks and the bouquets (or at least one half-hearted clap).
Heh. I am starting to feel better already.
Pair programming (for any developers who have been heads down in assembly since the 80s) is part of the extreme programming (XP), a methodology that takes a maximalist approach to software development productivity techniques. It involves lashing together two developers on one piece of code, ostensibly for reasons I will go into in more detail later. It is a bit of a mythical creature in places where I have worked, a boogeyman to scare developers into getting their coding act together. I have seen it lurking in the eyes of eager dev managers and team leads out to prove that they are up on the latest thing, but the threat was never made good.
That is until one deceptively innocuous meeting not too long ago.
I guess it was inevitable that at some point I would be staring down the barrel of this forced coupling and have to confront my deep and abiding loathing of intimacy with an unculled herd of colleagues as well as my fear of prematurely sharing half baked ideas with the pedantic nit pickers and self-identified geniuses that seem to be a staple of every development team.
Smothering my urge to quit on the spot I listened to the pitch. Pair programming was supposed to improve code quality, bind us all in eternal friendship and mind-meld our way out of knowledge silos. It would be the last piece of the Agile puzzle transforming us from clowns bumbling our way through missed deadlines to feature release ninjas .
Even over Zoom I could see the zealotic light in the dev manager’s eyes as he preemptively rebutted each of the objections I was muttering under my breath. I knew I was beaten. This thing was gonna happen and I better get used to it. I took a deep breath and set aside my prejudices like a grown up. It might actually work (I grudgingly conceded) and, hey, if we used best practices like taking breaks, switching roles and leaving time for non-pairing work, how bad could it be? The people on my team seemed like sane and rational individuals and I got on well with all of them.
Unfortunately, Utopian ideals falter in the face of human vagaries. Granted, pair programming is not exactly a gulag but dammit it feels like one (though at least there is coffee and an occasional snack). It did not solve any of the problems it promised to address and created a few new ones. Perhaps it would work in more favorable circumstances with the ideal mix of personalities comprising the team. The actual circumstances and personality mix, like most things in the real world, were the opposite of ideal.
Here’s a breakdown of the expectation/reality I experienced:
Expectation: 8 hour days with the recommended systems in place to mitigate against differing (often cross timezone) schedules, mental and physical fatigue, other commitments/ responsibilities and personality conflicts.
Reality: You stare bleary-eyed at the screen as your pairing partner fumbles his way around in obscure configuration files because, as we all know, changing random values always fixes whatever is causing your code to crash. Surely he must give up soon, you think. It’s 7:45 pm where he is and you have been at it since your hastily wolfed down breakfast. Is his stomach now growling? Does he not at least need to stand up to shake out a cramp in his leg? What happened to the timers? Where are the breaks, the role switching, the respect for other commitments and tasks?
Like many things, pair programming starts with good intentions which evaporate as deadlines approach and time starts running out. Panic sets in and all the processes meant to preserve sanity are tossed out the window. The team dynamics devolve into a passive aggressive Lord of the Flies scenario. Every day ends with utter exhaustion, acrimony and a mounting pile of unread emails that haunt your dreams when you are finally allowed to crawl your osteoporotic way out of your chair to bed.
Expectation: A strong and cohesive unit sharing ownership of the code and pulling together like a gold medal Olympic rowing team.
Reality: The loudest voice dominates the conversation. Whether it’s a cowboy ignoring instructions and unilaterally rewriting code when it is his turn at the keyboard or the team know-it-all who insists on using her pet framework, the project inevitably ends up stamped with one person’s style. There is a place for mentor/mentee pairing sessions but an entire project should not be implemented by a team where one half of a pair is either incapable of providing technical feedback or too timid to do so.
Expectation: An end to knowledge silos and situations where one guy quits and all of a sudden no one knows how to fix that one deployment script that is the lynch pin of the entire application portfolio. In my head I see senior developers guiding the juniors Yoda-like through swamps of legacy code.
Reality: The knowledge sharing is difficult when you are implementing a feature with a looming deadline. Usually the developer who knows the code will give a whirlwind tour through the more important parts before work starts in a specific area. As questions and problems arise, there is a lot of clicking and scrolling through more esoteric regions with many a “oh by the way…”. This would be fine except that there is no time to look at anything, or ask questions, as the navigator (this is a thing in pair programming, if you’re a code monkey and don’t know what it is consider yourself fortunate) is already dragging you on to the next thing. I have made a habit of quickly noting down the location of the code in these cases and then poking around on my own later. Usually it takes me thirty to sixty minutes to understand what a day’s worth of pairing has just obfuscated.
Expectation: Better code quality and faster development. With two brains bouncing ideas off each other and two eyes spotting mistakes
Reality: The pair programming I have participated in has caught a few typos and other fairly minor mistakes. I have yet to see it prevent larger errors in logic or avert a trip down the wrong architectural path (see the bit above about the loudest voices dominating). Discussing design challenges and getting a second pair of eyes on implementation are essential to code quality but these things are not achieved when one person is the puppet of the other blindly writing functions that they do not completely understand and have little time to absorb. Pair programming lacks the birds eye view of code reviews. Everyone is too busy dealing with the trees to notice the forest.
I will leave my musings about whether it’s possible to achieve developer productivity utopia for another post. This post is not about the difficulties of pair programming effectively but whether we should be trying to in the first place.
The thing is, even if we had followed best practices to the letter and somehow cleansed ourselves of our insufferable personality quirks pair programming would have still failed to achieve its lofty goals because of two critical shortcomings :
- Pair programming severs the brain/hand connection that is so important to shaping our thoughts into something coherent. How many times has the act of writing something out helped you really nail down an abstract concept? I frequently work out the nebulous ideas floating around in my brain through the physical act of typing (whether I am writing a post or writing code). What pair programming does is turn the person at the keyboard into a puppet of the ‘navigator’ who then becomes a backseat driver tossing out half formed and perplexing instructions that often lack substance.
- It ignores the fact that the people who are attracted to software development as a career are predominantly introverts (at least in my experience). They are often thoughtful people who like the solitude of their keyboard and monitor where they can contemplate tough problems in peace. They find social interaction draining even when they crave the company of colleagues in small doses (I am one of them!). For this reason, of all the productivity fads that have been inflicted on me over my twenty plus year career, pair programming has been the most distressing. I am angry that it has taken a quiet job and made it loud. I am angry that I had to spend eight plus hours a day being ‘on’ because if I was that kind of person I would be in sales. I am angry that all this misery was for little or no gain. Projects still got behind. Bugs and rework still happened.
Most developers I know are happiest and most productive when they can hammer ideas out in private before revealing them to the world. Having someone looking over your shoulder as you try out some cockamamy notion is guaranteed to be inhibiting (even if the audience is a completely sympathetic fellow nerd). Having to work out my thoughts on a screen share before they have at least gelled into some acceptable form makes me want to hide. It makes me want to churn out what is acceptable rather than what is good.
I am a huge fan of collaboration and I am not saying some young rascal straight out of comp sci should be allowed to commit modules written in Frege to the project repository with no oversight but why must everything be done in public these days like some Roman orgy where you are forced to expose yourself whether you want to or not? Programming should not adopt the unfettered exhibitionism of social media where every unfiltered brain spasm is tossed into the arena for public consumption.
Call me old and cranky but I long for the peaceful days of just me and my keyboard, heading off on coding adventures with no one constantly putting their two cents in and interrupting my train of thought. Work used to be fun. Staying up until the wee hours wrestling with an obscure bug or a tough challenge was exhilarating. Now I just watch the clock praying for the day to drag itself to its end.
As I strap in for another day on the pair programming chain gang I can’t help but wonder if Shakespeare could have written his plays or if Einstein came up with the theory of relativity had someone been shouting instructions at them from dawn to dusk. I am no genius poet or ground breaking physicist but I can come up with half-decent code if left alone to cobble my disorderly ideas into some semblance of a rational solution. Imagine how much brain power is wasted through this enforced socializing and constant distraction when it is inflicted on developers who are way smarter than me.
Fortunately, from what I can see, pair programming has not gained much traction, probably because, like me, the average developer has an instinctual aversion to this travesty of a practice regardless of the fake enthusiasm they trot out for management. It is, however, only one variation on a theme.
The world has always favored those who can get themselves noticed but lately it seems that whoever cannot handle jumping up and down constantly clamoring for attention will be left behind like the Commodore 64s and Tandies of yesteryear.
This does not bode well for introverts, or for humanity. We need people who can reflect and focus on one good idea to offset the flashy chasers of the next shiny thing if we are to produce something of real value.
Balance must be restored to The Force.
We need to rid ourselves of the fear that a little alone time will lead to irrelevance. Pair programming revived memories of my anxiety plagued high school years with their popularity contests and passive aggressive power struggles. To say that it did nothing to increase my productivity is an understatement.
For the good of the world, introverts unite! You have nothing to lose but your impotent rage!
