Software Practices That Sound Good but Often Conflict with Humanity – Part A: Pair Programming
Good but difficult to execute well in the real world, due to human reasons.
In this article series:
Part A: Pair Programming
Part B: Mandatory Code Review *
Part C: Code Traceability Matrix
Part D: User Story Points Estimation
Pair Programming is a core rule of eXtreme Programming, the first Agile methodology.
Definition of Pair Programming: “All code to be sent into production is created by two people working together at a single computer.”
I agree with Robert C. Martin: Extreme Programming (XP) is the best Agile methodology—better than Scrum and the rest.
Yet, despite being both the first and the most effective, XP never gained widespread adoption. Why? In my view, there are two main reasons:
1. The Name
Management tends to dislike the term "Extreme Programming." Neither word sits well—extreme sounds reckless, and programming makes it sound like something only developers care about. (One of my managers actually said this to me)
2. Pair Programming
Many developers aren’t comfortable sharing a single computer and working so closely with someone else. It challenges personal habits and preferences, making adoption harder than it sounds.
According to the Pair Programming on the XP website:
“Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.”
I totally agree. In fact, I personally quite like Pair Programming. Back in 2005, I learned a ton—Refactoring, Unit testing with Mocking, E2E Test Automation, Continuous Integration, Ruby, and more—by pairing with an agile consultant (later known as a world-renowned programmer) for six weeks. That experience completely shaped my career (for a lot better). I honestly wouldn’t be where I am today without it.
Speaking of that—and my first real experience with pair programming—it happened on a project where I newly joined a team full of senior Java contractors. Let’s just say... developers avoided pair programming. I was “volunteered.”
And what do you know—I hit the jackpot.
Just a couple of months later, I was promoted to tech lead—mainly because I became at least 5X more productive than my former peers. Proper end-to-end test automation and refactoring can work wonders. (Of course, I’d been practising everything I learned nightly.)
Later on, I started mentoring and pair programming with some of the new hires. The results? Overall disappointing. Why? Well, it was a government project, and we only hired experienced contractors—who usually had high egos and didn’t like pair programming.
The reason: they felt uncomfortable.
Unable to follow, but don’t want to express out (pretending).
Embarrassed by obvious mistakes, e.g. typos, wrong designs.
Unhappy seeing their code being changed or deleted.
By the way, I also did pair-automated testing with a few people. I remember one newly hired (not by me) senior test automation engineer seemed really uncomfortable with hands-on scripting with me. At the start, I told him several times, ‘If anything’s unclear, feel free to stop, and I’ll be happy to explain.’ But he stayed passive for about 10 minutes. I paused a few times and asked, ‘Can you follow along?’ He quickly replied, ‘Yes, yes.’ After another 5 minutes, I stopped and pointed to a statement on the screen, asking, ‘Do you understand what this XPath expression means?’ He responded, ‘What’s XPath?’
In a word, pair programming wasn’t well received.
Of course, there were exceptions. Below is a thank-you message from one developer I hired, with whom I had a few pair programming sessions. He thought of me after landing a senior manager role at Google USA.
With the rise of Scrum and the so-called Agile Ceremonies, pair programming slowly faded into obscurity, rarely mentioned anymore. Developers returned to their usual solo coding routines. I’m sure many programmers my age have experienced something similar.
To summarize, I think pair programming is great:
more productive
produce high-quality code
making code review mostly unnecessary
knowledge transfer
However, there are human factors to consider, especially with the new generation of programmers ( I am referring to the trend, not individuals)
Many young programmers don’t read books—something I see as a sign of a reluctance to learn.
In comparison, when I was younger, I had a habit of buying and reading at least one technical book per month.Another thing I’ve noticed is that many prefer coding with headphones on, which seems to be a sign of wanting to work alone.
There also seems to be a decline in social skills, perhaps due to the influence of social media and video gaming.
Disagreement, sometimes even on trivial things such as code formatting.
Unable to concentrate without refreshing Facebook or TikTok every 10 minutes
Yes, in an ideal team with motivated and eager-to-learn developers, pair programming offers great technical benefits. If I were the boss of a software company (which I’m not, and honestly, I have no interest in being—I'm enjoying my life as a solopreneur), I’d definitely make pair programming mandatory. However, software development is ultimately a human activity (ever heard of the book Peopleware?), and human factors need to be taken into account.
Related reading:
Benefits of Real E2E Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.
XP (eXtreme Programming) is better than Scrum, as XP defined DevOps 20 years ago
Interesting article, do you think with the rise of working from home that pair programming can be more comfortably achieved now that people can work together on one screen but still be working on their own computer?