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'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.
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.
You know, I'm not sure that's a counterexample. If there were six good and careful coders, I think I could be convinced that they'd make a more reliable system than a few hundred broken into several carefully-spec'ed and rigorously documented teams, where it would be much harder to avoid having a few bad apples, not to mention the impossibility of having even a general idea of what someone else's code is doing.
It's not a guarantee, no. But I don't think it's a knockout counterexample, either.
In research quoted in Software Estimation by Steve McConnell, for completing a medium sized project (in that research defined as 10,000 to 100,000 lines of code) there was a local minimum of calendar time with teams of 5-8 people. To reach that level of calendar time again you needed a team of at least 20 people. However there is reason to believe that 50,000 lines of code delivered by 20 people will have more duplication of effort and less quality than the same delivered by 5. Which makes the relative productivity of the small team even better.
The reason is simple. The natural loose and open structure of a small team breaks down if the team is too big. Depending on the specific people, it tends to happen somewhere in the range of 6-9 people. Past that you have to manage lines of communication carefully, which results in process and overhead with reduced productivity.
The lesson to draw from this is the following. If you want the project delivered as cheaply as possible, let one programmer work as long as it takes. If you need it delivered quickly you can increase team size to 5-8 people. If you need stuff delivered faster than that you'd better swallow hard, accept a several-fold increase in costs, start hiring, and do careful planning because you'll need it.
(You can pass the small team limit in practice by having different teams on different pieces of software. But they had better be really different. When people have to interact closely, they are part of the same team no matter what the org chart says.)
11 comments
[ 4.4 ms ] story [ 44.2 ms ] threadSo yeah, I agree.
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.
In other news, I don't understand why so many people would up-vote a post which is has almost no content and is ostensibly promotional.
It's not a guarantee, no. But I don't think it's a knockout counterexample, either.
In research quoted in Software Estimation by Steve McConnell, for completing a medium sized project (in that research defined as 10,000 to 100,000 lines of code) there was a local minimum of calendar time with teams of 5-8 people. To reach that level of calendar time again you needed a team of at least 20 people. However there is reason to believe that 50,000 lines of code delivered by 20 people will have more duplication of effort and less quality than the same delivered by 5. Which makes the relative productivity of the small team even better.
The reason is simple. The natural loose and open structure of a small team breaks down if the team is too big. Depending on the specific people, it tends to happen somewhere in the range of 6-9 people. Past that you have to manage lines of communication carefully, which results in process and overhead with reduced productivity.
The lesson to draw from this is the following. If you want the project delivered as cheaply as possible, let one programmer work as long as it takes. If you need it delivered quickly you can increase team size to 5-8 people. If you need stuff delivered faster than that you'd better swallow hard, accept a several-fold increase in costs, start hiring, and do careful planning because you'll need it.
(You can pass the small team limit in practice by having different teams on different pieces of software. But they had better be really different. When people have to interact closely, they are part of the same team no matter what the org chart says.)