Ola Hast and Asgaut Mjølne Söderbom gave a talk about continuous delivery with pair programming at QCon London. Their team uses pair and mob programming with TDD; there are no solo tasks or separate code reviews. This approach boosts code quality, reduces waste, and enables the sharing of knowledge. Frequent breaks help to maintain focus and flow.
The team does code reviews together, rather than sending pull requests back and forth, Mjølne Söderbom explained:
When Ola and I started on the same team in 2021, we decided to work together on everything. Not all agreed, so some of the team still worked alone, but if Ola or I were involved, they had no option – then it was pair programming.
Mjølne Söderbom mentioned that it is very powerful to have at least two team members who want to do pair programming. It can be difficult to try to convince a whole team by yourself. They also use pair programming heavily in the onboarding of team members. After a while, everyone understood this was the way to go, he said.
All tasks are suitable for working together, and no one ever sits alone with responsibility for a given task, Mjølne Söderbom said. A task always has at least two persons involved. If one is unavailable, the other can code alone, and then we just sync together again (for instance, if one person has to go to a meeting).
There are four developers in his team, a perfect size according to Mjølne Söderbom. If all four are available, they split into two pairs. Sometimes they do a mob with all four, if they are working on something new, or where they need to make bigger decisions. This way, they can spread knowledge before splitting up. If there are three, they always work as a mob, he said.
Mjølne Söderbom explained that they switch driver and navigator every 7 minutes, and every 10 minutes when in pairs:
When we are in the office, we use a cheap kitchen timer to keep track of the time. A few other teams on our floor have bought the same timer now, so it’s kind of funny when you hear the timer go off all the time! We also pair program when someone is remote, usually just with screen sharing in MS Teams.
If they have to switch machines when changing driver, they have a few aliases to quickly commit and push to git, Mjølne Söderbom said. They all have different keyboards and keymap setups, and sometimes it is just easier to move to another desk when switching. Aliases over the github cli also help us quickly create and approve/merge a pull request when they are done, he mentioned.
They do TDD on everything, and they love it, Mjølne Söderbom said. They spend no additional time on review since it is all done as part of the process. Since they pair and do TDD on absolutely all code, they do all review and architecture decisions as they go, he explained:
Some still claim that pair programming is only suitable for certain, often complex tasks. We learned that this is not the case; all tasks are suitable for working together on. In the long run, this drives speed and knowledge sharing in a completely different manner than before.
He has always been interested in clean code and code quality, and pair programming goes hand in hand with this, Mjølne Söderbom said. He cannot think of any other methods or tools that provide higher quality than working together, he concluded.
InfoQ interviewed Ola Hast and Asgaut Mjølne Söderbom about how they work in their team.
InfoQ: What’s your approach for measuring and reducing waste?
Ola Hast: The thing about working together with pairing is that when things like builds or processes take time, one starts talking about it. The first time is often fine, but when something takes time several times in a row, then it becomes a problem. We then start talking about solutions and workarounds.
Very often, what takes too long is a gut feeling, and handovers are often not noticed until you experience them firsthand. If you cannot do a repeating task without involving someone outside of the team, or if a specific task in the team requires a specific person, then this is a problem that causes delays and waste.
When people are working alone, we see a much higher acceptance of waiting, slow builds, and so forth. Working together really pushes us naturally to reduce this waste.
InfoQ: Does code need to be approved before it goes into production?
Asgaut Mjølne Söderbom: All forms of working in isolation (alone) mean that you have someone else to review and approve your code. Most companies have reviews as a compliance requirement. When pair programming, this is already done as part development.
InfoQ: How important is it to take breaks?
Hast: Working together, especially when you are really focused, is quite intense. So taking proper breaks where you are away from screens and keyboards is important.
Go for a walk around the block, get some fresh air. Whatever you do, don’t try to do other stuff, like checking email or Slack.
