I've worked in a few shops where management has passed the idea of pair programming either to me or another manager/developer, and I can't get behind it at all. From a developer stand-point I can't find a reason why moving to this coding style would be beneficial, nor as a manager of a small team have I seen any benefit.
I understand that it helps on basic syntax errors and can be helpful if you need to hash something out, but managers that are out of the programming loop seem to keep seeing it as a way of keeping their designers from going to Facebook or Reddit than as a design tool.
As someone close to the development floor that apparently can't quite understand from a book tossed my way or a wiki page on the subject… from a high level management position, what are the benefits of Pair Programming when dealing with Scrum or Agile environments?
Best Answer
Partly, it depends on how you are doing pair programming. In some instances, the driver of the pair is writing code, while the second member of the pair is observing and discussing the design and implementation details of the system. Another instance of pair programming involves both people writing code simultaneously - one person is writing the implemented functionality and the other is actively developing and writing test code at the unit and integration level, again discussing the design and implementation details of the system.
Regardless of the type of pair programming, it effectively serves as a continuous code review. You have two people's eyes on the code, watching for errors before they escape into a later system/acceptance testing environment or the field. You also have two people who understand a particular part of the system very well, to serve as a redundancy to minimize your bus factor. Both catching defects early and spreading system knowledge around the team reduces the cost of building a system.
The spreading of knowledge isn't just limited to the technical knowledge of the team, either. Depending on who the pair is, it can allow for information to flow between a more senior member of the company to a new member about other things that transcend the project - coding style, company culture, expectations, and so on. It can also allow someone who is more familiar with a technology or tool to share their knowledge in that technology or tool in a real-world applied setting.
As you mentioned, it also does help keep developers focused and in flow. In addition to flow, many individuals are less likely to interrupt multiple people working on something than a single individual working on something. If you walk by someone's desk and they are working alone, but you need to talk to them, you might knock and talk to them. This is less likely if you see two or more people collaboratively working or having a discussion - you won't interrupt them. Interruptions cost time, and spending more time means higher costs. It's in the best interests of the business to maximize productivity of the employees.
However, there are some challenges that must be overcome to make pair programming viable. Consider things like personality clashes or choosing the pairs to properly distribute the knowledge. There's also consideration of exactly when to rotate pairs. Pair programming done haphazardly probably won't be effective as one that's planned out. Depending on the makeup of your team, it might not be effective to pair people at all.