Pair programming and continuous integration can go hand-in-hand. Pushing to main multiple times a day is hard in isolation, leading to delays, large PRs, and merge issues, Ola Hast and Asgaut Mjølne Söderbom mentioned in their talk about continuous delivery with pair programming at QCon London. Pairing enables instant code review, easier refactoring, fewer bugs, and higher team resilience.
In an earlier article, Hast and Mjølne Söderbom mentioned that 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.
Pair programming and continuous integration (CI) support each other. Real CI means pushing to main several times a day, or as soon as you are done with a small task, Mjølne Söderbom said. This is hard to achieve when developers work in isolation, as every change requires external review and coordination:
If our team of four developers were to work in isolation/alone, it would be nearly impossible to work with real CI. They would have to interrupt each other all the time. The immediate result of this is that they produce bigger tasks with bigger pull requests. It also disrupts our own flow. Then the whole concept of CI falls apart. We see this happen in other teams all the time.
Refactoring becomes especially difficult if people work in isolation, often postponed with promises of “later,” which never happens, Hast said. When people work in isolation, it adds a layer of coordination to do much-needed refactoring, which either leads to merge hell or more promises of doing it later.
There is so much time wasted waiting in organisations, especially in the software industry. This wasted time seldom gets focus in organisations because it can be hard to see clearly, especially for management. Their way of working means that a lot of the processes that usually are a part of a development flow are superfluous, Mjølne Söderbom explained:
For instance, since we deploy very small chunks to production and have the ability to hide functionality behind feature toggles, testing in other environments just isn’t needed.
Mjølne Söderbom mentioned that they spend very little time reviewing code from pull requests since they do all review continuously while pair programming. It is not something we set out to do; it is just a natural consequence of working this way, he said.
When working together, you not only reduce waste during the task, but also greatly reduce waste on what we call rework; all the stuff that could happen after a task is “finished”, Mjølne Söderbom mentioned:
As we use TDD, pair programming, and CI, we are left with significantly measurable high value.
This gives fewer bugs in production, and even more importantly, the code is easier to change, and we can develop software faster in the future, he concluded.
InfoQ interviewed Ola Hast and Asgaut Mjølne Söderbom about refactoring and the benefits that their way of working has brought them.
InfoQ: How do you do refactoring?
Asgaut Mjølne Söderbom: Doing necessary refactoring is very difficult since it needs to be coordinated with everyone. People tend to say: “We will do this refactoring in another pull request later”. Which means never.
When working in small steps and putting code into production rapidly, we can easily do some tidying/refactoring, deploy that to production, then go back to whatever we were doing. This is a huge benefit for improving legacy code as you go
InfoQ: What benefits do you get from the way that you are working as a team?
Ola Hast: When you work closely with a small group of individuals over time, you get to know them rather well. So the psychological safety is high, the stress level is low, and we have a lot of fun working together.
The shared knowledge in the group gives us resilience, which is very helpful given that we both have small kids with all that entails, like sickness or school meetings. Someone being away is usually never a problem for our progress since we have continuity.
