Internetworkers: http://www.ibiblio.org/internetworkers/

[mdthomas at mindspring.com (Michael D. Thomas)]

> Having only really worked on non-death march projects, all I can offer is
some
> academic experience. Seems like Frederick Brooks wrote an entire book on the
> subject of what happens on a large software project. And while the Mythical
Man
> Month has a place within every business person's business-conscience,

It's my experience that there are many successful project managers in the
software industry that aren't aware of Brooks and his counter-intuitive
theorem:

"Adding people to a late software project makes it later."

These often seem to be same managers that say things like,

"We manage by getting 7 pounds of sand in to a 5 pound bag." In my experience,
there is little sand involved in software development, but this approach
supports Brooks's conclusion.... more on that later.

In the anniversary addition of his book, Brooks defers to the work of
Abdel-Hamid and Madnick who say:

"Adding more people to a late project always makes it more costly, but it does
not /always/ cause it to be completed later."

Stutzke's work expands on this and talks about how to best add people to a
late software project. Sometimes, you have to do it. 5 pound bags may suffice
when you have only 7 pounds of sand, but what about when you have 20? Then you
have to deal with the myth of the man-month and use a calculus more complex
than "For 20 pounds of sand, 4 5-pound bags will be sufficient, and b/c of our
management acumen, will actually be 8 pounds more capacity than needed."
Again, there is little sand involved in software development...

In my experience, Brooks's Law represents a project management dilemma that
can be optimized and de-optimized depending on the approach, team and culture.
In the worst case, you suffer from exponential dialog growth inside your
project. As you add people, the number of possible lines of communication
increase according to the equation n(n-1)/2. If everyone has to talk to
everyone, then you are headed for disaster. The active dialogs increase
exponentially, but time is a finite resource. Eventually, everyone's time is
mostly absorbed with coordination. Adding more people just makes it worse. As
more people are added, the amount of time any individual may spend on "real
work," rather than project intercommunication, approaches zero.

In more optimal cases, everyone doesn't have to talk to everyone. New people
can read documentation. Skilled and efficient communicators are appointed to
work with new team members. Group presentations are given. Most importantly,
work is partitioned effectively.

In 1995, 20 years after initial publication and after much discussion and
research, Brooks stood by his original assertion:

"The 'outrageously simplified' statement of Brooks's Law is made more useful
by these careful treatments of the proper qualifications. On balance, I stand
by the bald statement as... a rule of thumb to warn managers against blindly
making the instinctive fix to a late project."

"7 pounds of sand in a 5 pound bag" supports Brooks. It translates into
another oxymoronic platitude, "We expect 140% out of our people." Of course,
this isn't the language of communications theory, but of dentist's office
posters. But having been the bag many times, I can attest that I've delivered
more than I thought possible when "the bar was set high."

Taken as a management strategy, the sand bag analogy supports the assertion of
Brooks's Law by what it doesn't say. Brooks's Law advises managers to not
simply add more bags. That's where the analogy breaks down -- software
development has few homogenous components. Unlike the simple world of sand,
the bags are crucially interrelated, have learning curves, and aren't easily
replaceable parts.

[Eric Raymond also has some interesting refutations of Brooks's Law wrt Open
Source development. However, open source projects aren't as directly
constrained by time and don't have typical project managers, thus making
Brooks's Law itself less relevant.]

------

Academia and experience gives us many suppositions about software development.
Here are a couple of others I find worthy and accurate:

Conway's Law: "Organizations which design systems are constrained to produce
designs which are copies of the communication structures of these
organizations."

Conway's Law Corollary: "If you have four groups working on a compiler, you'll
get a 4-pass compiler"

Conway's Law is why software architects /must/ be involved in managing the
team, even though many software architects don't possess management skills.

SNAFU principle: "True communication is possible only between equals, because
inferiors are more consistently rewarded for telling their superiors pleasant
lies than for telling the truth."

The Cost Of Change Curve: The cost of change in a software project rises
exponentially as the lifecycle progresses from requirements through analysis,
design, implementation, testing and production.

http://www.softwarereality.com/lifecycle/xp/four_values.jsp

The cost-of-change curve is usually drawn as a smooth exponential curve. This
defies common sense -- in reality, it looks more like a step function as you
move through each phase of the lifecycle. The day software enters production,
the cost of change increases dramatically, not smoothly and incrementally.

The cost of change curve can also be flattened -- this is one of the basic
tenet's of eXtreme Programming. The most important way is to learn the value
of refactoring. Another way is common sense -- natural life cycles tend to be
neatly segmented. Just as people's educations don't stop after they leave the
"education phase," requirements, analysis and design can come up anytime in
the software development cycle. This is why a usable software development
cycle has to complement the software sales cycle that drives it.