Fundamentally the decision to allocate pairs to a task should not be collaboratively made by the development team, but rather made by the architect / manager based on feedback from team members. Some of the considerations an architect needs to consider include:
- Complexity of task
- Capability of the programmer(s)
- Competing priorities
- appetite for quality and therefore risk mitigation
This success of pair programming also relies on the management taking a proactive view on quality outputs. Which ever way you slice quality considerations, it makes for a better business. The difficulty is that too many manager's are focused on quick turn arounds and quick wins. I some words of advice for those managers, A sustainable business has to be built on quality! Jonathan Cogley ran an interesting little experiment on this subject. Check out his blog here.
