I sat on a panel for a conference last year with fellow owners of “boutique” software development firms. I use the word cautiously, as I’m not completely sure what people mean by boutique in this context, but there are usually implications of small size, specialization, and expertise. One of the more engaged audience members worked for a large, multinational company which created integrated hardware/software products. He challenged us, the panel members, as largely irrelevant to his company because of our sizes. A single project at his company, he pointed out, would consume every single developer in any of our small companies (the companies represented on the panel ranged in size from 10 to 50 people).
I’ve since learned that the sizes of the companies on the panel weren’t unusual for our industry. For the NAICS code 541511 (“custom computer programming services”), 85% of companies have annual revenues less than $1.2M. That in turn means that the vast majority of companies employ between 5 and 8 full-time developers. If anything, this data says the companies on our panel skewed toward the larger end of the spectrum for this industry.

Could most of the companies of our entire industry really be irrelevant to this large multinational firm with a huge, unmet demand for software development? Another possibility is the assumption made by our challenger was flawed. Maybe his projects don’t really need to have 30+ developers?
A study done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient.QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large”...