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.

[vhold]

But it sure would be an interesting experiment though.. Assuming there was already a common goal, what do you think would happen? Assuming there is some quality to the engineers, I think they'd immediately recognize the need for organization and the first problem they would solve is establishing that by some kind of engineered process. Without a formal process, I think the natural leaders would emerge as the people who spearhead the most agreeded upon initiatives, people would naturally align themselves with the projects they feel most comfortable with.

But doing that with -120- people would be pretty nuts. I've seen natural hierarchies emerge in pools of 10-15 people working on a project, but 120 would definitely be something else. A big factor that I've seen with natural leaders emerging from a pool of previous equal individuals was the leaders' initiative to acquire neccesary resources. Whoever acquired neccesary resources first is

If you ran an experiment with preacquired resources that nobody involved was responsible for acquiring, I think the natural method of acquiring a leader would become seriously muddied by politics instead of practicality. Acquiring resources is something that can be demonstrated immediately. Spending them is something you can't judge until it's too late if you are wrong.

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

Re:sure, ask a carpenter

[Jerf]

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 seen that makeover show, I think it's on ABC, that has done just that? One house in particular actually had to have foundation work done on it. (I don't watch it routinely, just caught it a couple times.)

I actually don't say this to disagree with you. One of the reasons neither my wife nor I can really stand to watch that show regularly is we both know you can't build a house from the foundation in a week... but you can build a television set from the foundation in a week. We have a rather strong suspicion that as neat as these houses look on TV, and as cool as they look on the surface (eliciting the cries of joy from the new owners), that these people are really just getting television sets. And those are no fun to live in.

I don't know, I'd love to be wrong, but the suspicion that these make-over-ees are getting boned wrecks the show for us. If 20/20 or equivalent show from another network followed up on one of these homes after a year or two, and everything was peachy within reason, maybe I wouldn't feel this way. But I suspect "peachy" wouldn't be the right word.

Re:sure, ask a carpenter

[LordNimon]

True, but if you can get nine women pregnant, you get to say, "Yeah, baby!"

(with apologies to Austin Powers)

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.

I think I should point out

[ikkonoishi]

That all of them aren't coders.

120 people seems to include all the artists and map designers as well.

Art works a lot more smoothly than coding when you have a large number of people.