# Concrete alternatives to inverse relationship between project completion time and number of developers?

## Background

It is now well understood (if not always well communicated) that the following logic does not apply to software development project estimates:

A project that would take 1 developer 12 days,
would take 2 developers 6 days,
would take 3 developers 4 days,
etc.

or as eloquently put by Fred Brooks in "The Mythical Man-Month",

Nine people can't make a baby in a month.

There are, of course, several factors that cause this, including necessarily-sequential tasks, more difficult communication, etc.

Mathematically, this model is equivalent to suggesting that project completion time T is related to the number of assigned developers N by an equation of the form

T = E/N

where E is the time required for a solo developer to complete the project.

## Question

Are there any other proposed relationships between project completion time T and the number of assigned developers N that

1. can be expressed in a reasonably succinct mathematical equation;
2. have been compared favorably (or at least more favorably than T = E/N) to data from real software projects?

• Whatever the equation is, coffee and donuts will almost certainly be factors. – Robert Harvey Feb 25 '16 at 23:17
• On a more serious note, I find it amusing that you think human behavior of any kind can be expressed in the form of a mathematical equation. – Robert Harvey Feb 25 '16 at 23:20
• If necessary, please use C and D for those inputs ;) – stkent Feb 25 '16 at 23:20
• "I find it amusing that you think human behavior of any kind can be expressed in the form of a mathematical equation" - not actually claimed; I would, however, not be flabbergasted if aggregated data taken from a focused collection of related situations could be shown to be fit better than by the extremely simplistic T = E/N if using some other model. See e.g. en.wikipedia.org/wiki/… for data-supported models of population-level trends of increasing complexity (and presumably, efficacy). – stkent Feb 25 '16 at 23:23
• Certain kinds of human behavior get very predictable at large scales, but I assumed you didn't mean programming using the population of a small country. – Robert Harvey Feb 26 '16 at 7:56

You are talking about software estimation.

The seminal, canonical references on software estimation are Barry Boehm's "Software Engineering Economics" and Tom DeMarco's "Controlling Software Projects".

Boehm's book is where you start, even if it is 35 years old. His biggest contributions are (1) the recognition that the estimating equation is inherently nonlinear, (2) the use of actual data over a significant number of projects to calibrate an estimating methodology, and (3) the recognition that certain factors like tools, team capability, and schedule compression or expansion will change the estimated effort. (Compress the schedule and total number of man-hours goes up. Expand the schedule and total man-hours goes UP.)

Step 1 is to estimate effort, in something like man-hours or man-days. Step 2 is to turn the man-hour estimate into a nominal estimated schedule, usually in days, weeks, or months, and a nominal team size. Step 3 is to revise the man-hour estimate, using the actual schedule dictated by what some have called the high-rafter bats (aka upper management, or maybe Sales or Marketing).

DeMarco's biggest contribution is the idea of an "impossible region": Some schedules are simply impossible to meet, no matter how many bodies you throw at them, no matter how good they are.

Shortly after Boehm's book came out, General Dynamics Fort Worth Division adopted his methodology, and calibrated their own estimator to their own actual data for F-16 software development. They then proceeded to bet the company's bottom line every time they estimated an F-16 software modification task.

My first experience with COCOMO was while I was there: I was more than a little surprised when, on an internal project, I discovered that Boehm's "punch in the numbers and turn the crank" methodology yielded an estimate that agreed quite closely with my personal gut feeling.

I find it more than a little dismaying when I see people using linear estimators ("10 lines per man per day", or some such) EVEN TODAY, 35 years after Boehm's book was published.

Once you have taken a pass through Boehm's book, you can look at the update: "Software Cost Estimation with COCOMO II". The original COCOMO, from 1981 or so, did not scale to "more modern" (translate: many times larger) projects.

After you have digested the above three books, THEN you can look at Steve McConnell's "Software Estimation: Demystifying the Black Art". DON'T try to skip straight to McConnell's book.

• Thanks, this is a great answer! It also led me to this Wikipedia page, which links to several other interesting estimation schemes. – stkent Feb 26 '16 at 3:54

I think you are slightly wrong with your assumptions.

I believe it is generally accepted that adding new developers does speed development up, but only up to a point. That point is generally considered around 5 developers. After that, as you assume, the communication overhead and lack of paralelizable tasks either doesn't decrease the time or even increases it.

If I were to cite a "The Mythical Man-Month" as you do, Brooks suggest a development model, where teams are composed of 5-7 developers and then those teams are part of "bigger team" where only selected representatives communicate from each team communicate with each other. This keeps the communication overhead low while allowing to have huge amount of developers working on a project.

• It's also important to note that how much benefit you get depends on when you add more people. Having more people at the start of a project is more beneficial than adding more people midway through. Iin the first case everybody's ramp up happens at the same time, and in the 2nd the new people's ramp up time comes at the expense of some performance from the people that were already working in the project. – Iker Feb 26 '16 at 6:50
• Ah, yes, this is a good point; so in a hypothetical equation that describes T in terms of N, T likely remains proportional to 1/N for small enough N (where "small enough" probably scales based on the size of the codebase/project), but that relationship breaks down for larger N. This seems reasonable! – stkent Feb 26 '16 at 14:47