Large Dev Teams Do Not Make For Quick Dev Cycles

Josh Bennett writes "1UP has a recent interview with Splinter Cell Chaos Theory Producer Mathieu Ferland where he talks about the difficulties in developing the game. In the article, Ferland said there are 120 people working on the game. That's not unheard of for a big budget EA game, but those games come out every year and the new Splinter Cell is taking more than two years at this point. Interesting read."

Comments

No duh, you friggin idiot.

[Safety Cap]

In any group, the number of communication paths is

C =
n(n=1)/2

Obviously, the larger the group, the more communications events that it will require to get the job done, but it is not O(n).

A team of two developers only has 1 communication path.
A team of 10 has 45.
A team of 20 has 100.

News for social misfits, stuff that is glaringly obvious.

Re:No duh, you friggin idiot.

[MalleusEBHC]

That's why you have *gasp* management! I know the word management generally only conjours up images of PHBs to most people here, but the only way you are ever going to get a group of 120 people to work towards a communal goal is to break them into units (and most likely sub-units) and have the managers handle the inter unit/sub-unit communication. That way the people on the bottom can go about working on their little section of the game while their manager makes sure their section fits in with the rest of the groups.

I fear the day anyone thinks this is a load of crap and sticks 120 engineers together on a project with no sort of leadership hierarchy.

Re:sure, ask a carpenter

[El]

My favorite quote is "You can't make a baby in one month by getting 9 women pregnant." All projects can be broken up into smaller tasks, but most tasks simply do not parallelize very well, so your critical path remains the same no matter how many bodies you throw at the problem. Also, the interface between one person's area of responsibility and everybody else's must be clearly documented. With a single developer, he spends 100% of his time getting things working and 0% of his time documenting interfaces. With a large group, most spend 90% of their time documenting and explaining their own interfaces and learning other people's interfaces.

Stunning revelations from the 1960s!

[cbiffle]

Sounds like some more people should read Brooks' Mythical Man Month. There's a reason this 40-year-old book still inhabits my bookshelf at work.

'Course, from how EA seems to treat their programmers, it sounds like they're not really considering any human aspects of the cycle, so I suppose this is not surprising.

Re:sure, ask a carpenter

[vasqzr]

You can't build a house in a week no matter how many men you throw on it. After a point, your returns diminish.

Have you ever seen Habit for Humanity build them in one day?

The only thing you have to wait on is the cement and paint to dry.

The Tao of Programming

[RayMarron]

From the Tao of Programming (http://www.canonical.org/~kragen/tao-of-programmi ng.html):

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''

``It will take one year,'' said the master promptly.

``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''

The master programmer frowned. ``In that case, it will take two years.''

``And what if I assign a hundred programmers to it?''

The master programmer shrugged. ``Then the design will never be completed,'' he said.