Perhaps the first example of pair programming began in the 1940s, with the very first programmers Jean Bartek and Betty Snyder. Jean said in an interview “Betty Snyder and I, from the beginning were a pair and I believe that the best programmes and designs are done by pairs, because you can criticise each other and find each other’s errors. And use the best ideas.’ The father of Visual Basic from the 1970s, Alan Cooper says that when he first started programming, it was a solo skill performed by individuals with little or no sharing, and virtually no collaboration. And so it was quite a different world 30-40 years after Jean Bartek and Betty Snyder.
Birgitta Boeckeler is Principal Developer at ThoughtWorks. She explained that most of the applications to jobs at their company have limited experience with pair programming which shows something about its adoption: “So if we had that as a hard requirement to only hire developers who have strong experience with pair programming, we probably couldn’t hire very many developers.” She gave a talk at Codemotion Berlin in 2019.
Why the pushback on pair programming?
Birgitta attributes this to two things:
- It’s a long game: “You can see short term benefits, like less errors, and you have to do less rework, because you have two people working on the thing together. But ultimately, it’s a lot about medium to long term, consistent quality and maintainability. And you might not see that immediately. And as developers, we also like the gratification of making something work today, and right now, and that’s also something that we share with project managers sometimes maybe, because for them also, pair programming feels counterintuitive, doesn’t it half the productivity of the developers
- It’s kind of hard: So you don’t just go and sit at a desk and there are two programmers and you do the same thing that you did before. There are just challenges that come with it.
The seven wastes of software development
- Partially done work
- Extra features
- Relearning: “Somebody on the team has already figured something out. But then you have to figure it out again because they’re not there, or they didn’t document it.”
- Handoffs: The quiet knowledge that’s not explicit. “So if you lose 50% in every handoff after one you only have 50% of the knowledge left. After two it’s only 25% of the original knowledge and so on and so on. And pairing can help you reduce Use those handoffs and also build up tacit knowledge and two people at the same time, so you have some backup.
- Delays
- Task switching
- Defects: “One of the core ideas of pairing is that you have two people who do just in time quarterly review and who put their knowledge together. So you want to actually increase the quality. That’s one of the ultimate goals. You want to avoid bugs and errors.
Pairing enables true continuous integration
Typically, every developer tries to integrate into the master at least once a day. When you pair program is akin to ‘code review on the go’: “You don’t have this asynchronous back and forth and have to wait for your review to then maybe merge into master.”
Pair programming also faciliates a lot more collective code ownership. So more people see more parts of the code and everybody feels a bit safer about what’s actually going on. And both of those things actually creates more create more safety for everybody to integrate into master.
Challenges with pair programming
Pair programming is not pain-free. Birgitte spoke about a number of challenges in making it effective:
1. It’s exhausting: “One of the things that we often see when a team is really committed to making pair programming work is they start pairing eight hours a day, and that’s actually not sustainable.
When working by yourself, you also do things other than coding. Try to incorporate that into the pairing routine. So plan your day together all the different things you need to do taking breaks for other communications or meetings.
She advises people to take breaks regularly and switch roles so that you take turns writing for example.
2. Communication: “Pairing is a form of quite intense collaboration and we’re often not used to that. So we actually have to talk to each other and get to know each other and our habits to a certain point so that we can figure out how to work with each other. So feedback is really crucial here. And the pairing is actually a great opportunity to practice giving and receiving feedback.
3. Habits and pet peeves: Pairs need to create a clear way to get to know each other’s needs. Usually this is not instinctual and needs to be communicated directly, “For example, some teams exchange Read Me’s e.g “I need to go for lunch at 12:45pm or I get angry.”
4, Juniors and seniors are not always a good team: Sometimes people think it’s really good idea if you have more junior people on the team, you pair them with the more experienced people, so that they can learn from those more experienced people. “But pairing is not necessarily just a learning exercise, it’s about a lot more than that. And sometimes it’s actually not a good idea to have a really experienced person pair with a very junior person. Because for the very experienced person, it might be very hard for them at this point to explain certain things whereas the junior person might need very clear rules in the beginning to then later learn how to break them.”
5. Some people just don’t work well together: Some people just don’t click and are better working with others.
6. To pair requires vulnerability: It means sharing all that you know and all that you don’t know. That’s only constructive or helpful if you actually have this situation where both people open themselves up and are both vulnerable. And also accept that criticism and try to improve collaboration.
Is it worth the hassle?
There’s a whole list of skills that you need to work on such as improving concentration, communication and giving and receiving feedback. But as Birgitte notes, these are all things that you need anyway, on a highly effective team. She shares that “I also feel like it made me better as an individual developer because now I feel like I always have all these people kind of on my shoulder, telling me things as I’m coding to ensure I’m doing my best.”
