Five developers is the maximum that I will put on a project. That doesn't mean the larger hunk of software doesn't have other teams working on it; just that they need to be separated by a well defined API (service based or otherwise). If the project isn't big enough yet then you don't need that many developers.
I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I'm not big on the pair thing; not saying it doesn't work for a lot of people but I just don't care for it in my projects. I like it for doing code reviews or going through to tighten things up, but not as an all-the-time development strategy.
If you want a better guarantee of having 3 pairs, go with 7 developers. Then you're covered when one is sick/on vacation/on jury duty/off getting married/stuck at the DMV, etc., and you've built in some insurance in the event that one of your coders gets run over by a bus.
Comments
Five developers is the maximum that I will put on a project. That doesn't mean the larger hunk of software doesn't have other teams working on it; just that they need to be separated by a well defined API (service based or otherwise). If the project isn't big enough yet then you don't need that many developers.
So yeah, I agree.
6 developers makes 3 pairs.
I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I'm not big on the pair thing; not saying it doesn't work for a lot of people but I just don't care for it in my projects. I like it for doing code reviews or going through to tighten things up, but not as an all-the-time development strategy.
If you want a better guarantee of having 3 pairs, go with 7 developers. Then you're covered when one is sick/on vacation/on jury duty/off getting married/stuck at the DMV, etc., and you've built in some insurance in the event that one of your coders gets run over by a bus.