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:No duh, you friggin idiot.

[sporty]

You don't have the developers talking to each others directly. You have lead developers or architects talking to each other. THey agree on deliverables and communicate changes that way. Instead of having a * structure, you have a small star with offshoots.

Re:No duh, you friggin idiot.

[ChaosDiscord]

Several people have pointed out that management is supposed to solve the problem. Indeed, with good management you can have a team of 120 working quite effectively.

However, mediocre to bad management is far more common than good management. With mediocre or worse management the team ends up routing around management problems and reestablishing those hundreds of communication paths. Thus, your pessimistic estimates are reasonable for real world situations.

The key is good management. Finding and retaining good management is left as an exercise for the reader.

Re:sure, ask a carpenter

[mcmonkey]

I've got nine women lined up; I'll let ya know in a month if we've made a baby.

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.

Mythical Man-month still applies

[xmas2003]

Slashdot reviewed Fred Brook's classic The Mythical Man Month way back in 1998. This book was actually written in 1975 based on is experience in the 1960's ... so while the /. review is 6 years old, it still holds true today and applies in this situation IMHO ...

Re:C'mon

[Anonymous Coward]

Slashdot Rejection Form

This article is about:

( ) bashing MicroSoft
( ) music or movie piracy
( ) hackers
( ) somebody patenting a worthless idea
( ) what Sun is doing wrong

Although it fits one of our major categories (above), your article
was rejected because it:

( ) wasn't rabidly pro-Linux
( ) wasn't sufficiently ironic
( ) made too many Star Trek references
( ) failed to link to a low-bandwidth server
( ) promoted your own crappy website too prominently
( ) was too right-wing or too centrist
( ) had correct grammar and spelling
( ) referenced Fark, Kuro5hin, The Reg or the Mainichi Daily News,
all of which are frequently more entertaining than we are.

On the positive side, your article had some of the characteristics
that we are looking for:

(x) creates a certain sense of deja vu
(x) makes a wild speculation unjustified by the referenced article
( ) mentions an outrageous lawsuit or criminal trial
( ) announces a minor BSD patch release
( ) explains a new idea for space travel
( ) uses the word "teraflops"

Keep sending and sooner or later we will mangle one of your
submissions.

Thanks

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.