Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as too broad by gnat, GlenH7, MichaelT, jwenting, Bart van Ingen Schenau Sep 30 '14 at 8:15

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Software involving research, multi-disciplinary studies, government undertakings, huge data analysis are large projects that require a few hundred programmers working in tandem. And IMO, software gets complex with the purpose rather than people – Ubermensch Feb 23 '12 at 8:19
up vote 3 down vote accepted

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).

share|improve this answer

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 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 pulls on dozens of these services (aggregating in the UI). Works for them. Enormous app made up of manageable bite-sized chunks.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.