Experiment: Pair Programming By Default
As you could already read in some of our previous blogposts, we are a relatively small team, with some loose rules for working together. Up until one month ago, everyone just picked a project from the roadmap and started implementing, and there was a rotation system within the team to always have two people available to help out our support team to assess bugs & fix issues respectively.
💭😰 About Silos & Issue-Fatigue
As you can imagine, this works really well for projects that are small and well defined, and for teams where everyone is of the same skill level, and has the same development practices. People are not in each other's ways, and you can "horizontally scale" your team. The only trouble is, we're a small team, we have senior and junior developer profiles, and our projects are mostly not so small. The result of this, is that the person implementing a feature is most likely the only one that really knows the feature inside out. So the bus factor for every feature was basically 1. For some features we had insane knowledge silos.
There's a similar story to the support rotation system within the team: the people talking to support and fixing bugs most likely didn't implement the features where the bugs appeared. If they did, the bugs were quickly fixed, and if not, people had to try and understand code written by someone else that they'd never seen over and over again. Not ideal. And the result was that for me personally, weeks when I was Batman (yes that's how we call the lucky engineer that's solving bugs that week) were the most draining periods of the year.
⚗️🔬 The Experiment
We do weekly roundups, and after an exhausting week of being Batman, I, expressed my feelings towards the Silos and the Batman weeks. The whole team actually agreed that the situation was not perfect, and we decided it was time for an experiment:
- Split up the (already small) team in two groups of people (3 to 4 people per group) that will always try to work together on the same feature.
- Start every day together with your team (at the same computer or over Slack Voice Calls) trying to solve issues or create features using Pair Programming techniques. Split up the team for "monkey-jobs".
- Both teams provide one team member per week to be Batman or Robin. They form their own team and tackle bugs together.
We limited the scope of the experiment to the winter release, so 3 months. So far we did a (very limited) retrospective every week.
👩💻👨💻 What have we learned so far?
We've only been doing this for 4 weeks, so I might be jumping to conclusions here. So far the experience has been positive!
- It's great to be able to verify your ideas immediately, and to try and build a shared understanding of the problem you're working on.
- Pair Programming is exhausting, but it works! We feel the velocity gain and the concentration boost. We find that we're writing better code. We feel productive.
- We're aware that it's exhausting and we take a lot of breaks, stop early when we're tired.
- We're using Slack as team communication tool, and when someone is working at home, we can just keep Pair Programming because of the built-in voice calls and screen sharing. Slack even allows you to share your mouse and keyboard with the person at the other side of the call (that is, if you've installed Slack from their website instead of from the App Store).
- We found this great blogpost with some basics to keep Pair Programming digestible, by my friend Wouter Sioen.
- We've done some ad-hoc pair programming in the past, but starting the day at the same computer really helps you keep it up and encourages you to do it more often.
- Batman and Robin are way faster at finding and fixing bugs than when they were working alone. Having that extra developer by your side improves your bug finding experience massively. When working alone, overlooking a small mistake could take up hours, while your pair could spot that in seconds. Our CTO Jurriaan Persyn pointed out that we've fixed a third more issues than last month, even some that were open for a long time already!
📚🧐 Some resources
- Tuple's Pair Programming Guide with lots of good tips!
- Blog: Pair Programming For Introverts
- Blog: How To Keep Pair Programming Digestible
- Blog: Martin Fowler on Pair Programming Misconceptions
- WikiWikiWeb on Extreme Programming
- Great twitter thread by @MrAlanCooper about Pair Programming
- Mathias Verraes talking about Pair Programming for quality
We hope we can keep it up! 🤞