3 ms·

> "large teams are likely to operate in environments where large teams are required due to bureaucratic overburden" Exactly. A four-person team may be far mor

by roc 15y ago

> "large teams are likely to operate in environments where large teams are required due to bureaucratic overburden" Exactly. A four-person team may be far more efficient on-task, but requirements-gathering and politicking at a large company could swamp them for months. There do exist problems so large that simply defining them exceeds the capability of a four-person team. Furthermore, a small team's ability to bring in a project for less money ignores that time is a business-critical aspect of development. In many cases it is worth far more to a company to get a solution out the door in 12 months at greater expense than to wait for a more cost-efficient team to finish in, say, 24. Lastly, I take issue with the entire idea of efficiency being definable as cost-per-line-of-code. If we as a profession are going to dismiss SLOC as a useful measure of productivity, we certainly can't turn around and allow it to be the basis for an efficiency argument.

raganwald 15y ago
In many cases it is worth far more to a company to get a solution out the door in 12 months at greater expense than to wait for a more cost-efficient team to finish in, say, 24. I ask whether we can just take it as a given that large teams can get a given piece of software done more quickly than a small team. It may happen some of the time, it may not. But I have trouble granting it as axiomatic, for reasons that would require a blog post to list: http://weblog.raganwald.com/2007/08/bricks.html http://weblog.raganwald.com/2007/08/bricks.html
- sliverstorm 15y ago
  If you are discussing variances of a few percent in team size, sure- there is an optimal size and it may be smaller than we expect. But do you really expect you could write a project the size of, say, Linux or Office, with a four-man team faster than a hundred-man team? Even if half the latter team is utterly useless, and the team runs 10% the efficiency of the four-man team, you still have more production power. Obviously it costs twenty times as much, but as a previous poster noted, sometimes that just doesn't matter.
  - raganwald 15y ago
    Both of your examples are extremely interesting! Tell me: Did they start with 100s of people?

by roc 15y ago

raganwald 15y ago

In many cases it is worth far more to a company to get a solution out the door in 12 months at greater expense than to wait for a more cost-efficient team to finish in, say, 24. I ask whether we can just take it as a given that large teams can get a given piece of software done more quickly than a small team. It may happen some of the time, it may not. But I have trouble granting it as axiomatic, for reasons that would require a blog post to list: http://weblog.raganwald.com/2007/08/bricks.html http://weblog.raganwald.com/2007/08/bricks.html

sliverstorm 15y ago
If you are discussing variances of a few percent in team size, sure- there is an optimal size and it may be smaller than we expect. But do you really expect you could write a project the size of, say, Linux or Office, with a four-man team faster than a hundred-man team? Even if half the latter team is utterly useless, and the team runs 10% the efficiency of the four-man team, you still have more production power. Obviously it costs twenty times as much, but as a previous poster noted, sometimes that just doesn't matter.
- raganwald 15y ago
  Both of your examples are extremely interesting! Tell me: Did they start with 100s of people?