About 10% of developers ‘do virtually nothing’
Stanford research in developer productivity has identified 0.1x engineers.
Two years into pair programming: The good and the challenging
In an attempt to speed up our development process, my teammates and I took a somewhat controversial route – we introduced pair programming. And it worked.
The team comprises developers with different backgrounds and levels of experience. The idea was to use pair programming to level the team and make everyone faster and more independent in developing new features. We already had positive experiences with pair/mob sessions when troubleshooting production problems or supporting our users (other engineers and support teams), so we gave it a go.
We’ve been at it for two years and are happily reaping the benefits.
What is pair programming?
Even though programming in a pair has been practiced since the dawn of programming, the practice was first introduced to a broader audience in the 90s. In his excellent book “Extreme Programming Explained” from 1999., Kent Beck defined pair programming as follows:
All production code is written with two people looking at one machine, with one keyboard and one mouse. […]There are two roles in each pair. One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically...
Kent Beck, Extreme Programming Explained, 1999
Today, there are more options for pair programming than sitting together in front of a computer with one keyboard and mouse, from simple screen sharing to specialized tools like Code With Me from JetBrains. However, the above-mentioned principle remains the same.
I heard about pair programming long ago and was always intrigued by it, but I hadn’t had practical experience before we introduced it two years ago. I heard a lot of positive experiences with it, and the success stories were impressive.
There is also a fair amount of skepticism, whereas the main concerns are that pair programming is expensive, slow, and necessarily ends in frustration – everything you would like to avoid in a team. And diametrically opposed to what we were trying to achieve.
Rocky start, stellar results
As the team was already collaborative and had a proven record of great teamwork, we weren’t afraid of pair programming ending in infighting. And yet, we were off to a rocky start.
Although everyone was theoretically up for trying pair programming, we didn’t want to make it mandatory. This meant that, in reality, people were quite shy about asking for pair programming.
One of the issues was that they often didn’t deem a feature valuable or complex enough to have two developers working on it, or there was pressure to code a feature as fast as possible – and talking about it all day long seemed like a waste of valuable time. There were also some social fears: What if other team members saw everything I don’t know, what I have to Google, how slow I am?
We gave up on pair programming on routine, repetitive, and simple tasks because we didn’t get any added value. In that case, pair programming did prove too expensive. But, when adding new features, we saw more and more benefits.
It also took us some time to figure out how to be productive without frustrating each other with unhelpful comments and remarks. We found ways to work through things that bothered us (talking to team members can solve almost anything, right?). We took a pause when needed or moved programming sessions to different times. We didn’t use any specific tool for pair programming, just screen share and audio call.
Despite our hesitations, even the first pair programming sessions were a positive experience – mainly because we all learned more than we expected not only about programming, frameworks, or tools we used but also about the domain and the feature/problem we need to solve.
We noticed that the ratio between talking and coding was much higher than we expected. Since we better understood the problem, the developed solutions and code were better than they would have been if we were coding alone.
Better readability, predictability, and quality
In the beginning, the most experienced team member was the driver of most sessions, and we rarely switched roles during sessions. Still, we were noticeably more productive than working alone.
We paired for 3-4 hours a day, as we had other operations and support we needed to attend to. Not to mention that pair programming requires complete focus and can be exhausting, so 3-4 hours per day was the maximum anyway.
Focus was strictly on the task at hand, without the usual interruptions (Slack, mail, phone…). We never got stuck on a problem and always learned from each other. Exhaustion aside, we were satisfied with the progress, and the results were better and more predictable than coding alone.
After a few months, we started with pair programming more often and switching roles. That’s when another positive side effect surfaced: The code was always readable because if it wasn’t, you immediately had questions about it.
The code quality, in general, was very good. And by quality, I’m referring to Dave Farley’s description: “The ability to change software easily, safely, and with confidence is a marker of its quality.“. I would say that the solutions we implement regularly are the best that team could implement (in a similar timeframe), regardless of the way of the work.
When we switched to trunk-based development, the experience was even better. My favorite part was no pull requests or pull request reviews. The code was reviewed continuously, and since we had solid automated tests, we got all the benefits of continuous integration.
Mob programming
If two programmers do a better job than one, then three, four, or more programmers must do it even better, right? After our initial success with pair programming, we decided to try mob programming as well.
Whether you call it mob/team/ensemble/collaborative programming or software teaming, the practice follows Woody Zuill‘s definition from “Software Teaming” book: All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.
Or, in more practical terms:
Software Teaming is a software development approach where the whole team works together on the same thing, at the same time, in the same space, and at the same computer. This is similar to Pair Programming, where two people sit at the same computer and collaborate on the same code at the same time. However, with Software Teaming, we extend the collaboration to everyone on the team while still using a single computer for writing the code and doing other work.
Woody Zuill, Software Teaming
We were doing mob programming sessions online, sharing screens the way we do when pair programming. It showed the same benefits as pair programming but wasn’t much of an upgrade from it.
We noticed it was even harder to stay focused. Usually, the driver and one navigator were actively paying attention, but others got distracted by other work. We opted to do more pair programming sessions instead but are leaving our options open.
Since we have been spending more time at the office recently, we will try to do mob programming sessions live to see if it makes a difference. If you’d like to know more about mob programming or try it out yourself, check the aforementioned book “Software Teaming.” Dave Farley also has a great video on the topic, and Thierry de Pauw shared a lot of practical tips & tricks in this thread.
Intrigued? I certainly hope so!
Pair programming and trunk-based development have proven to be an excellent combination for us. We also started practicing test-driven development with more discipline to see if it would improve our work. That combination resulted in continuous progress and predictive feature releases every time we used it.
If this article has motivated you to try pair programming, here are some great resources to get you started:
- On Pair Programming – Birgitta Böckeler, Nina Siessegger
- Key to Pivotal Software’s success: Pair programming! (Rob Mee)
- I’ve Pair Programmed for 30,000 Hours: Ask Me Anything! — Joe Moore
- You Must Be Crazy To Do Pair Programming • Dave Farley • GOTO 2022
- Remote Pair Programming Good Practices – Thiago Ghisi
And if you are already pair programming, share your experience with me on Twitter or LinkedIn!
