I have a mild critique of this: Small teams can get a lot done, and there certainly is a diminishing return per extra developer on any team, but most development isn't slow because it has too many people but rather the problem being solved has become large enough that a small group can't keep all of it in its head.
Eventually, those three programmers have built so much that even with their productivity, their entire time is spent on maintenance. Replace 3 with N programmers, especially understanding the diminishing returns.
Then take into account that if one experienced programmer leaves a small group, picking up that domain knowledge takes a significant amount of time. While having a team of 50 makes each engineer slower, it means that losing one or two isn't a company-altering event.
In my experience, "the problem being solved" can very easily be "how can we have 120 developers committing to this code base without going insane" and that's the only hard part.
Comments
I have a mild critique of this: Small teams can get a lot done, and there certainly is a diminishing return per extra developer on any team, but most development isn't slow because it has too many people but rather the problem being solved has become large enough that a small group can't keep all of it in its head.
Eventually, those three programmers have built so much that even with their productivity, their entire time is spent on maintenance. Replace 3 with N programmers, especially understanding the diminishing returns.
Then take into account that if one experienced programmer leaves a small group, picking up that domain knowledge takes a significant amount of time. While having a team of 50 makes each engineer slower, it means that losing one or two isn't a company-altering event.
In my experience, "the problem being solved" can very easily be "how can we have 120 developers committing to this code base without going insane" and that's the only hard part.