Reconsidering Pair Programming
We gave pair programming a fair chance but I'm afraid it didn't work out.
After a nine month experiment with pair programming, we decided that it is not a good fit for us. Here's why:
- It doesn't guarantee that the best design is chosen. It might be slightly better than what a single programmer would come up with but ideally the developers with the most experience in software design should take the lead when it comes to the design of the system.
- Since a pair discuss their implementation amongst themselves they neglect to document their decisions and communicate them to other members in the team. It is still better than a single developer keeping it all to himself but it doesn't guarantee discussion about design and architecture in cases where it is really required.
- Mistakes are very costly. If you bill your customer by the hour and a pair took the wrong avenue, your customer have to pay double for that day's mistake.
- It generally requires to much coordination and synchronisation and really doesn't cater for individual differences. Some developers like to code in the early mornings and some like to burn midnight oil and others like to keep on going when they are in the zone. So if one developer in a pair has a family and needs to knock off at five, he often breaks his partner's rhythm.
To achieve the same level of quality and knowledge transfer that pair programming promises, while being more flexible at the same time, we practice the following:
- Standup meetings every morning.
- Daily code review by a senior developer.
- Developers have to document their design and implementation before they start coding.
- Designs need to be reviewed by a senior developer before coding can start.
Developers generally don't like documenting what lies ahead of them, but they have to fight against the urge to just jump in and start coding. I think it is essential for developers to learn to express the design of a system in a narrative, both verbally and in writing. This helps them to design better systems and increases the maintainability of their software. In short, I think good developers are good story tellers.
