Under which circumstances will development advance faster with many contributors compared to few? [closed]

Question

I saw an interview with Joel Spolsky, where he says that Fog Creek Software intentionally keep their teams small (I believe as in four-five guys). The reason for this is to avoid a lot of the communication needed between the team members if the teams are larger. If one compares this to open source projects, where there can be hundreds (or thousands?) of contributors. Whether they are a team, is, though, arguable. There are probably also examples of something in between, with team sizes of 20 developers.

My question is: What kind of software is most suited for getting developed by small teams, and what kind of software is suited for large teams?

Answer 1

If you speak with the guys working on large projects such as the linux kernel (epic amount of work done by many devs) you will find that they are working in loosely knit small 'teams'. A known set of contributors works on a particular feature, usually under 5.

Out of that team one is the feature owner, and is part of the team for a larger feature, and so on and so on until you get to Linus who is the product owner.

Think of it as small commando teams. This is the organizational version of the 'divide et impera' pattern in software. You take a problem and split it up into smaller problems until it becomes manageable.

The number and size of the teams should always be dictated by the experience of the 'owner' of the feature/product. If you don't have enough experienced people for the features you are doing, either get some more so you can have more teams, or schedule your project so they have enough time to do the tasks.

Having a team that is too big causes serious problems in the long run (look up Vista development).

Answer 2

A few general thoughts on practices I've seen work (regardless of team size & type of software):

• continuous integration attitude
• clean interfaces across tiers (e.g., SOA)
• strong leadership
• test-driven culture
• automation
• mature adults (not (necessarily) "old" but just not immature jerks)

I think Amazon.com has "2 pizza teams" - no bigger than can be fed with a couple of pizzas. They are also big into services (SOA) and own their services end-to-end (dev & ops). A page on Amazon.com pulls on dozens of these services (aggregating in the UI). Works for them. Enormous app made up of manageable bite-sized chunks.

Answer 3

Some software projects are by their very nature so large that they could not be done in a reasonable amount of time by a small team. An example of this would be a large operating system or database product.

It is a question of math really. For example I remember a rather simple by today's standards operating system that had 2.5 million lines of code. Assuming a programmer could produce 100 lines of debugged, tested and production ready lines of code per day (very optimistic) then this would take one person 25,000 days or roughly 68.5 years working 7 days a week!

In project management there are methods to optimize team size vs project duration to minimize cost. Of course the need to get to market quickly will often cause firms to put more people on a project than is optimal from a cost prospective in order to attempt to get it done faster.

Where possible on small projects it is generally better to keep the team smaller rather than bigger. This way there is less time wasted in administration, meetings etc. and it is easier to insure that everyone understands the vision and remains on the same page.

A seminal work discussing these issues is the book The Mythical Man-Month: Essays on Software Engineering by Fredrick Brooks.