The developers at daftcode have taken the time out of their busy coding schedule to bust some myths about pair programming. They first talk about the problems that mature teams have, among them are: slower learning, silos, keeping up code quality. Then they discuss the specific myths that need to be busted.
Many developers can relate to the code quality issue where it becomes a chore to ensure that code reviews are happening and to ensure that the reviews are covering the right things (architecture vs trivial coding style fixes). The review process requires a few passes as well which slows things down. It is not uncommon for large teams to have pull requests that are not closed for weeks and that are reviewed 3 or 4 times over by multiple people.
Then there is the issue that the review process is tossed out the window as soon as a hotfix is required. It becomes acceptable to have only one person quickly review the change when in that situation the reverse should be happening and more eyes should be on the code to make sure the hotfix doesn’t break many other things.
Pair Programming Myths Busted
The myths that are gone through are:
- pair programming will double the workload
- it will only work with the right partner
- pair programming is only good for training
- I’ll get no credit for my work
- the navigator finds only syntax mistakes
The article is very good at busting the myths and we at Software Dev Group have encountered many of the myths at our own workplaces.
The first myth is the most pervasive, everyone seems to think that pair programming means that two people are assigned to one task. That is a naive view that does not take into account that the pair will not only fix the bug or implement the feature but will also be learning from one another and about that part of the code base. In the future, fixing or further adding to the feature will take less time because they already have the right knowledge to make things happen.
Synergy in Pair Programming
The article lists the behaviors that result from the synergy of pair programming:
- pair pressure: pressure by each other to focus on the work instead of being distracted
- pair negotiation: more ideas for design and implementation
- pair reviews: code reviews happen immediately
- pair learning
- pair trust: increase trust between peers about their code and design skills
- pair courage: tackling a nasty bug or a large refactoring becomes easier
- pair debugging: especially when paired with someone already familiar with that part of the code base, the bugs get fixed faster