Comparing small and large team projects I've been involved with...
Small teams... "Do the work..."
Large teams... "Do the process..."
By process I mean a pre-defined set of steps, documents and stages. And, often these stages do not fit naturally with the work.
On 10/5/05, Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
From an outsider, it seems that more manpower WOULD be better, within reason.
It seems to me that creating software should be somewhat similar to
any other engineering project. My hospital has been adding a new
wing for the last year or so, and it certainly wouldn't have gone up
faster if there had been LESS people working on it. There has to be
some optimal number of people to work on each aspect of element/stage
the project, and then there is the interdependence of stages (can't
start step 5 until step 4 is done etc.)
I am also interested in following the computer gaming industry (which
by the way earns more each year than the movie industry, for the last
two years). Consider a typical 3D game. It requires the following
basic elements:
- base art creation
- 3-D model creators
- 3-D model animators
- game shell to run levels
- game level creators
- music composition
- sound effects
- overall story creator
- management team
- database functionality (if MMOG)
It seems to me that within each aspect of the project, you are going
to have more productivity with more manpower--albeit with deminishing
returns at some point. e.g. 6 modelers will get the game's resources
created faster than 2 would, but 20 modelers might not be able to work
at 100% effeciency. So I can imagine creating a graph with X=number
of workers and Y being the total productivity. The curve would start
out with a straight 1:1 increase, but then flatten out at extra
workers help less and less.
So the issue would be as to how much the project can be divided into
truly unique aspects. There was a comment before that division of the
project causes the individual parts to loose site of the whole, and to
get demoralized etc. Perhaps that would be because the parts were not
as unique as in my example above. In my example, I can't image that
one person could be the musician for a game, and also a database
programmer. But if you had two teams both working on databse issues,
there could be problems.
Anyway, enough writing about something that is completely outside my
area of expertice! I have woken up way to early this morning (4:00
am), and I think I'm rambling a bit.... :-)
Kevin
On 10/4/05, Gregory Woodhouse < [EMAIL PROTECTED]> wrote:
> Fred Brooks was a hopeless optimist.
>
>
> ===
> Gregory Woodhouse
> [EMAIL PROTECTED]
>
> "One must shy away from questionable undertakings, even when they have a
> high sounding name."
> --Albert Einstein
>
>
>
>
>
>
> On Oct 4, 2005, at 5:29 PM, Ben Mehling wrote:
> On 10/4/05, Nancy Anthracite <[EMAIL PROTECTED] > wrote:
> > I have been trying to recall, but I think it is something like doubling
> the
> > number of programmers quadruples the time it takes to complete the
> > project ...or something like that.
> >
>
> > On Oct 3, 2005, at 10:51 PM, Nancy Anthracite wrote:
> > > I have I heard this before as an aphorism with a lot fewer word but
> > > exactly
> > > the same meaning. As I recall, I heard Rick Marshall pass it on
> > > as a quote
> > > from someone else about what happens when you add more programmers
> > > to a
> > > project.
>
> I'm going to guess you're thinking of the 'classic' book Mythical
> Man-Month?
>
> http://en.wikipedia.org/wiki/The_Mythical_Man-Month
>
> - Ben
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
