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” teams (greater than 20 people).

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Given that the large teams averaged 32 people and the small teams averaged 4 people, the cost of completing the project a week sooner with the large team is extraordinary: at $10,000 per person-month (fully loaded employee cost), the large teams would have spent $1.8M while the small teams only spent $245k. [Update: Team size isn’t necessarily uniform over the calendar duration of the project, therefore you can’t multiply the calendar duration (~9 months) by the cost per person month to get total project cost. The costs I’ve shown use the total person months of effort (24.5 for the small teams, 178 for the large teams) as given in the QSM study.] I can’t think of too many situations where gaining one week in the schedule could possibly justify this cost differential.

If I use the QSM data and compare the cost of a large, internal team of employees versus a small, external team from a “boutique” software development firm, the cost advantage is still huge. Even at a rather high $150/hour, the small team of contractors would only cost $600k versus the $1.8M of the large internal team.

How can small teams be so dramatically more efficient than large teams?

Communication and coordination overhead rises dramatically with team size. In the worst possible case where everyone on the project needs to communicate and coordinate with everyone else, the cost of this effort rises as the square of the number of people in the team. That’s such a powerful effect, in fact, that a large team couldn’t possibly hope to achieve the goal of everyone coordinating their effort. But a small team could.

QSM found another explanation for the huge cost differential between small and large teams. The defect rate for the large teams was five times greater than for the small teams. Defects consume time in discovery, documentation, and repair. That effort is obviously necessary, but doesn’t contribute directly to creating the desired software, and therefore inflates cost without any benefit to the schedule.