This is like pair programming except you don’t have to cut your productivity nearly in half.
To clarify: I’ve always believed that most of the benefit from the practice comes from the fact that work is actually being done for an increased portion of the time in front of the monitor, and that the costs and benefits of discussion roughly balance.
Anecdotal, but my experience of pair programming is that it’s incredibly useful for picking up bugs as they are laid down rather than having to dig them up later. Not to say that being monitored working doesn’t help, but finding and removing bugs is by far the hardest and most expensive part of programming.
Pair programming reduces variability in productivity rate, so looking back on a pairing session you should expect to remember occasions when you felt that you’d been slowed down, and should not expect to have noticed occasions when you’d saved time.
Alistair Cockburn has a study up somewhere showing (from memory) a small increase in work hours to first thunking you’re finished, a large reduction in bugs, and an improvement in subjective measures if code quality. Trike’s experience matches this study—we think pairing is awesome. .
This is like pair programming except you don’t have to cut your productivity nearly in half.
To clarify: I’ve always believed that most of the benefit from the practice comes from the fact that work is actually being done for an increased portion of the time in front of the monitor, and that the costs and benefits of discussion roughly balance.
Anecdotal, but my experience of pair programming is that it’s incredibly useful for picking up bugs as they are laid down rather than having to dig them up later. Not to say that being monitored working doesn’t help, but finding and removing bugs is by far the hardest and most expensive part of programming.
Seems reasonable and is supported by some study linked in Wikipedia. Code review is supposed to do this more efficiently, albeit with higher latency.
Pair programming reduces variability in productivity rate, so looking back on a pairing session you should expect to remember occasions when you felt that you’d been slowed down, and should not expect to have noticed occasions when you’d saved time.
Alistair Cockburn has a study up somewhere showing (from memory) a small increase in work hours to first thunking you’re finished, a large reduction in bugs, and an improvement in subjective measures if code quality. Trike’s experience matches this study—we think pairing is awesome. .