In the vast landscape of software development methodologies, one timeless technique has stood the test of time — Pair Programming. Many teams avoid this technique due to unfamiliarity and the upfront cost required. Indeed, it’s hard to justify doubling the resource, going from 1 engineer doing 1 task to requiring 2 engineers to do 1 task, not just once, but every week continuously.
So, how did it go in a real workplace? Let me tell you my experience.
The Abyss of Team Dysfunction
I’m in a team of 6 engineers. My teammates are all very smart people and are each familiar with a system they frequently work on. After joining the team, I also get familiar with another system. As time goes by, we do more and more tasks that change our systems, and we don’t really care about the other ones.
Almost a year passed, and I realized that we have a challenge. A disconnection among teammates hindered effective collaboration, making it difficult for team members to back each other up. Project timelines have to extend more and more frequently due to the siloed approach where each member handles only their familiar system. The growing complexity, intensified by the constant influx of new features, led to stress, a lot of stress.
We used to have a culture of doing talks. A talk is basically a 30-minute to 1-hour meeting organized by a team member to share anything they want. Mostly, people share about technical problems and solutions at work, or even at their school in the past. I think we learned a lot from each other this way, but that is long gone now. We don’t have time to do talks anymore. Even worse, we can’t even onboard new members properly.
In short, the team cannot “scale” further, and it’s time to take action.
Our Beacon: Pair Programming
Although costly to start, research has shown that Pair Programming is a practical and beneficial solution in the long run. The study “On the Economic Feasibility of Pair Programming” shows an approximate 15% longer development time but highlights the subsequent benefits in terms of higher code quality, better design, and lower bug counts.
Additionally, Cal Newport’s exploration in his book “Deep Work: Rules for Focused Success in a Distracted World” emphasizes the unparalleled results that stem from intense focus, which he calls Deep Work. Pair Programming inherently fosters focus much like a deep work session.
Why is that so? Because it shields both programmers from distractions and procrastination. In my opinion, this is the key motivation.
Armed with research insights, our team decided to venture into the realm of Pair Programming. We scheduled Pair Programming sessions at least once a week. The pairing changes after each week, so each engineer has the chance to work with as many teammates as possible. Simultaneously, a dashboard was deployed to anonymously monitor the bug resolution time of team members, providing a tangible metric to track progress.
Emergence from the Depths
As the weeks unfolded, the dashboard unveiled a promising transformation. Bug resolution time gradually decreases, pointing towards the positive impact of Pair Programming on code quality and problem-solving efficiency. The collaborative sessions not only improved the technical aspects but also forged stronger relationships among team members.
The most surprising result is that it actually decreases our development time! This is because each engineer brings different skills and knowledge into the session. So when Tom doesn’t know where to find the logs, Jerry can jump in to help because he knows it. As a bonus, members began to confidently take on tasks of other systems, breaking down the silos that had plagued the team for so long.
After three months of Pair Programming, the results spoke for themselves. We are happy with the success and decided to continue the Pair Programming sessions until now.
In conclusion, our journey through the abyss of team dysfunction to the summit of collaborative success strengthens the result of research studies. Pair Programming, an age-old technique, proved to be the beacon guiding our team out of the abyss, offering a practical solution that not only improves code quality but also cultivates a positive and efficient working environment.
References
- “On the Economic Feasibility of Pair Programming”, Laurie Williams and Hakan Erdogmus
- “The costs and benefits of pair programming”, Alistair Cockburn
- “Deep Work: Rules for Focused Success in a Distracted World”, Newport, Cal
Top comments (0)