By Jack Ganssle

Team Sizes

Published 10/26/2005

When the IBM 360 tools project started running late managers hired more programmers. And then they iterated this process, eventually boosting team size from the projected 150 to over a thousand developers. They found that each new batch of hiring slowed the project dramatically. Fred Brooks recounts in his seminal must-read "The Mythical Man-Month" that the effort eventually ran years late and dramatically over-budget.

As a result of this debacle he formulated the thesis now known as Brooks Law: adding people to a late project makes it later.

Barry Boehm's Constructive Cost Model (COCOMO), used for estimating software schedules, mirrors this finding. As projects grow in size individual productivity plummets. There's an exponential relationship between the schedule and the size of the project as measured in thousands of lines of code. Typically COCOMO predicts that as a program swells to the million line of code mark programmers will each crank just 17 lines of code per month.

The reason is communication, of course. A small project done by one lone developer has zero comm channels. it's all in Joe's head. Two folks have a single link. The number of channels is N(N-1)/N, practically an n**2 rate. Pretty soon, with enough people, everyone is so busy attending meetings, responding to email, writing reports and it's rare they have time to leak out a line or two of code.

Microsoft puts armies of developers on big projects like Windows and Office. Could this be contributing to the embarrassing delays in Vista (ne‚ Longhorn)?

Of course it's impossible to deliver 50 MLOC with only a dozen people on the team. But it is possible - perhaps mandatory - to partition projects into small bits and pieces, each logically distinct, each of which can be implemented by a handful of programmers.

What's the situation in the embedded world? One 2001 survey found that the average embedded project used about 7 developers, a surprisingly small number. Yet firmware content doubles every 10 months to two years, depending on who you believe, so this data may not represent the situation today. It's not uncommon to have a million lines of code anymore, which is a huge effort likely to consume the efforts of hundreds of developers.

Yet teams of that size are fairly rare. A lot of these giant projects are organic, having evolved over the years from smaller apps as features and functionality get added from one release to the next. Sometimes a newly acquired company has a big code base that gets integrated into the buyer's products. I've run into a couple of groups managing humungous chunks of code with only a handful of developers.

Today's business mantra dictates doing more with less. But that doesn't square with skyrocketing code sizes.

How big are your projects. and how many developers do they use? Are there enough. or too many?

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: