Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming The Almighty Buck Entertainment Games IT Technology

Large Dev Teams Do Not Make For Quick Dev Cycles 55

Posted by Zonk from the throw-more-monkeys-on-the-pile dept.
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."
This discussion has been archived. No new comments can be posted.

Large Dev Teams Do Not Make For Quick Dev Cycles More

Large Dev Teams Do Not Make For Quick Dev Cycles

Comments Filter:
  • ...it's called Splinter Cell Chaos Theory?
  • Comment removed based on user account deletion

    • Re:sure, ask a carpenter (Score:4, Funny)

      by mcmonkey ( 96054 ) on Friday November 19, 2004 @01:58PM (#10866883) Homepage
      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 (Score:5, Insightful)

      by El ( 94934 ) on Friday November 19, 2004 @02:02PM (#10866927)
      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:sure, ask a carpenter (Score:4, Informative)

      by vasqzr ( 619165 ) <vasqzr@@@netscape...net> on Friday November 19, 2004 @02:06PM (#10866980)
      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.

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

        Wow!

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

        Oh, wait, wasn't that the whole point? Concrete still takes a few days to dry and all that.

    • Re:sure, ask a carpenter (Score:3, Interesting)

      by Jerf ( 17166 )
      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 f
  • for something like 25 years, and people are just now figuring this out?

  • No duh, you friggin idiot. (Score:5, Informative)

    by Safety Cap ( 253500 ) on Friday November 19, 2004 @01:52PM (#10866806) Homepage Journal

    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. (Score:5, Insightful)

      by MalleusEBHC ( 597600 ) on Friday November 19, 2004 @02:24PM (#10867220)
      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.
      • 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
      • That only works if get Linus as your manager. :-P

      • That's why you have *gasp* management!

        Competant functional management can indeed handle this, but it takes more. The project itslef must be designed to facillitate modular sub-division. Each module can then be developed by a much smaller sub-team werer the number of communications paths will be small. In turn, the sub-team leaders must meet as a group but will also have fewer communications paths to deal with.

        Poor management can sabotage that sort of thing by regularly 'inviting' the whole dev team t

    • Yes, but can't most information be broadcast, instead of communicated point to point? E.g. send a single email to everyone on the team, don't compose a separate email to answer a single person's questions. (Ok, this still adds overhead on the receiving side, where each receiver has to filter out all the stuff they already know or didn't want to know.)

    • Re:No duh, you friggin idiot. (Score:4, Insightful)

      by sporty ( 27564 ) on Friday November 19, 2004 @03:08PM (#10867824) Homepage
      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.

      • 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.

        That's all well and good in theory, but a "chinese whispers" effect soon puts the kybosh on that.

        Imagine this scenario: programmer in the widgets team talks to team leader (widgets) who talks to team leader (I/O) who talks to programmer in the I/O team.

        • Documentation documentation documentation, especially in a large group. If something is described as working one way, and then it is changed, the written documentation must be cahnged and made clear what is going on. This includes unit tests and examples if necessary.
          • Again, fine in theory. Of course, in the real world you run into "I'm too busy coding to do documentation" (sometimnes found with "I'm too busy coding to read documantation" or (my personal favourite) the source code pasted into a word document.
            • Then its the manager's fault for not following a protocol for a large development group. *period*


              And I've worked in small and large groups, where it's failed and succeeded all that random times.

              • Then its the manager's fault for not following a protocol for a large development group. *period*

                Never said it wasn't - and if you've only ever worked for good managers, on projects with good processes, then you're lucky. The same loss of meaning with spoken communication also arises with written communication - especially in a multinational. Sure you can then QA the documentation and specifications, but that adds even more overhead.

                Maybe I'm getting cynical in my old age, maybe it's because I'm working

    • Re:No duh, you friggin idiot. (Score:4, Informative)

      by ChaosDiscord ( 4913 ) on Friday November 19, 2004 @03:41PM (#10868368) Homepage Journal

      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.

      • Additionally, the notion of bad management seems pervasive within the technical community even though it's not always justified to blame management. Some projects are simply very hard to manage effectively. The more people you have on a project, the more distributed general and specialized knowledge becomes.

        I guess what I'm trying to say is project management is hard and it gets harder the bigger the mess becomes. Blaming managers, as tempting as that may be, is not always the answer. More to the

  • could it be, that adding programmers is a lot like adding processors.. doubling doesn't quite result in 200%, as more and more resources go towards coordination?

    btw, the article SUCKED, i went in expecting to read even just a little bit about large-scale-development and all i got was a crappy 2-page splinter-cell advertizement. that and firefox asked to install 2 different plugins so i can better experience further, flashy-er advertizements on my plain-text advertiziment.

  • Stunning revelations from the 1960s! (Score:5, Informative)

    by cbiffle ( 211614 ) on Friday November 19, 2004 @02:05PM (#10866971)
    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.

  • Mythical Man-month still applies (Score:4, Informative)

    by xmas2003 ( 739875 ) on Friday November 19, 2004 @02:13PM (#10867071) Homepage
    Slashdot reviewed Fred Brook's classic The Mythical Man Month way back in 1998. [slashdot.org] 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 ...
  • I don't understand why this article is worthy of discussion. If you actually RTFA, there is very little to discuss..

    • With a recently announced delay pushing the release to March, a staff of roughly 120 people, and the development cycle pushing past the two year barrier, Splinter Cell Chaos Theory isn't exactly being pieced together by two kids in a garage. But according to the game's Producer, Mathieu Ferland, that doesn't mean it's been an easy game to make. We recently sat down with Ferland to find out

    • the _REAL_ reason why they have 120 against 60 is that they can afford it with their shiny bigger budget because splinter cell is now a 'hit' franchise.

      the sad thing? if previous games by anyone are to go by.. humongous teams don't make imaginative games... it's not even a guarantee that it's polished(unless you coun't the ea's yearly games.. they're pretty polished but then again they've been polishing them for the past 6 years..).

      blablabala buzzword1 blablba buzzword2 blabla so we need double the people

  • I'm not buying EA again after they did. (Score:1, Interesting)

    by Anonymous Coward
    I just won't support a tyrannical company who uses their employees like a pirate ship used pirates. Go steal the treasure (Do all the work, get killed), sail the high seas (get scurvy, die), and when the treasure is buried you all get disposed of because you aren't needed anymore. EA worked them to the bone, disregarded their families, and probably gave them various mind sicknesses from lack of sleep. I hope the ex-workers in the class action lawsuit take EA for all they can.
  • Wasn't Ion Storm already testament to this fact? If memory serves, the Daikatana team was large, and everyone knows that game's saga.
  • Battleship not as nimble as speedboat, say boffins.
  • Maybe the develpment team has been worked to the bone and they're just not as productive as when say they get sleep. If you don't know what I'm talking about, read the previous and more recent articles on working conditions for EA. I'm starting to think EA really stands for "Everybody takes it up the Ass"!
  • too many cooks spoil the broth... maybe ID could tell you about it

  • The Tao of Programming (Score:4, Insightful)

    by RayMarron ( 657336 ) on Friday November 19, 2004 @03:53PM (#10868516) Homepage
    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 (Score:3, Informative)

    by ikkonoishi ( 674762 ) on Friday November 19, 2004 @05:53PM (#10870220) Journal
    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.
  • Large herd of buffaloes takes more time to cross river than small herd..

    No real or imagined similarity between programmers and buffaloes is implied.
  • YNSA == Yeah, no shit, asshole

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close