As I wrote earlier, I attended my first ever Alt.Net un-conference this weekend. It was a rewarding experience, and meeting fellow developers in such an informal setting was fantastic. The open spaces were particularly valuable.
One of the open spaces I participated in focused on Pair Programming. The discussion quickly evolved into how to persuade developers, management, and others that it’s a beneficial practice.
Here is a recap of some of the insightful points from that session:
Good Ideas
- Switch the keyboard often: One developer writes the test and another handles the implementation, or use a Pomodoro timer for ten-minute intervals.
- Switch partners frequently: For example, once a day.
Arguments for the Benefits of Pair Programming
- It’s fun! This alone is a strong argument. Enjoying your work is essential.
- Here is a list of benefits and some studies showing improvements in quality.
- It may be slower initially but leads to faster production in the long run.
- Higher quality due to immediate feedback from the partner.
- More familiarity with the codebase among team members.
- Increased concentration with fewer interruptions, both internal and external.
- Here is a paper indicating that while there may be a 15% tempo loss, the quality gains are substantial.
If there are still doubts, try pair programming for a sprint and assess the results. Adjust what isn’t working as needed.