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

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.

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.

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.