Dogs, cats and pair programming clichés
The dog is man’s best friend, the cat is less demanding and always falls on his feet, it’s not so much the heat but the humidity that gets you down and blah blah blah. Clichés have always been part of our lives (and maybe even this is a cliché itself)!
Inevitably, even the world of programming and technology is full of them.
Today, in particular, I’d like to talk about some clichés about Pair Programming, one of the most talked-about Agile practices.
Pair Programming has always been full of many clichés with which it is judged negatively by many people, questioning its actual effectiveness: today we debunk the three most common myths.
Pair Programming and its clichés
Let’s start from the beginning: what is Pair Programming?
In short, Pair Programming is an Agile software development practice in which two developers collaborate on the same piece of code, working side by side. If you want to learn more, check out my video dedicated to the topic on my YouTube channel (for Italian speakers) or this article which I found very explaining!
This practice involves several topics of discussion: having two developers work together, at a first glance, could appear as an obvious waste of time and money.
Extrapolating a few themes from an article by Martin Fowler about it, I found myself particularly in agreement on three of these topics in particular and I’ll try to explain why they are actually clichés without concrete foundations and what benefits Pair Programming can bring instead!
Doubled costs
The first one is the most “dumb” criticism that is made to the Pair, which is a doubled cost. Fowler has the perfect answer for this statement:
It would be true if the hardest part was writing the code.
Boom. The end. It’s all there.
It’s all there because supporters of the practice strongly believe that a Pair session is much more productive than two developers working separately; the reason is simple: working in pair, thanks to the continuous discussion and immediate feedback that comes with it, you get a better design, you make fewer mistakes and you’ll have more people familiar with the code.
All of this totally pays back for having “fewer people typing”.
It’s always important, however, that the team decides to implement it on their own and periodically reflect back on the team’s feelings about the results, benefits, or disappointments derived from Pair.
Mandatory if you are an XP team
Pair Programming is certainly one of the practices that are part of eXtreme Programming “by the book”; this cliché assumes, therefore, that these practices are mandatory. This statement seems trivial but, as Fowler himself admits, it is much less than it seems.
However, there is one thing: we must always remember that we are talking about Agile methods, in which by definition the team is free to choose the practices and processes it considers best for itself. Quoting Kent Beck’s “Extreme Programming Explained”:
Practices are the set of things you see an XP team doing every day.
So you can agree that Pair is a common practice for an XP team, but not doing Pair doesn’t necessarily mean you can’t be considered an XP team anymore: the fundamental principle remains to be effective, without being bounded by definitions.
Must be avoided on trivial developments
Of the three clichés we’re talking about, this is definitely the most valid, in a way: we can say that it has its own logic. Pair Programming has among its purposes to improve the design and minimize errors, so on very trivial and fast developments, it could be excessive giving minimal benefits.
But watch out for those situations: if they happen often and repeatedly, it should sound like an alarm warning you that, perhaps, we are missing some abstraction in the design.
Conclusions
Surely, there are many other commonplaces about Pair Programming, but these ones struck me in a particular way because they are clearly wrong right after a short period of use of the practice.
The main advice I can give you for your first sessions of Pair Programming is definitely to be participative; whether you are Driver or Navigator, try to feed a constructive conversation with your colleague to reach a shared design and share as much knowledge as possible.
