Developing games with large teams

As the video game industry has grown, so have the the expectations of the customer and accordingly product complexity. Time pressures however have remained more or less constant, while there are a few products that ship "when they are ready", most still have to ship for Xmas, for the end of a fiscal quarter or the start of some sports season.

As a result team sizes have ballooned over the last 5 years or so, it's a predictable solution to the problem, with predictable problems of its own. The old adage that 9 women can't have a baby in 1 month is pretty much understood by everyone involved, having said that there are plenty of people involved who still believe that 20 women can have a baby in 5 months.

There are some things you can do on a large team, that small teams simply can't do you have resources to burn, so you can do experiments or add features that a smaller team simply couldn't afford too. However the cost of this is extreme, when lots of people are contributing to a codebase, the codebase will be necessarily larger for the same functionality, larger means more complex and more difficult to maintain, engineers generally have only local knowledge of the codebase, often coupled with an incomplete or inaccurate understanding of the rest. Because of the increased engineer count, there is a tendency to have a disproportionately high number of inexperienced engineers. Code quality becomes difficult to police and you start to suffer from "death by a thousand cuts" in both performance and memory.

The mistake that is commonly made is to believe that you can control this from the top, by adding separate engineering/project management and tracking the project at a finer granularity. This IMO as two fundamental problems with it, project managers staring at there planning tools start to look at engineers as work units, and the completion tests look at features in isolation rather than in the context of the game as a whole. This leads to a loss of ownership by the individual contributors and a lot of unscheduled time to take the collection of features built this way that have to be cut/fixed or reimplemented before the game actually ships.

Now I'm not advocating no planning or tracking, they are both very valuable tools in managing any project. But it's important to do everything in the context of the game, and understand that estimates are estimates, rather than pressuring an engineer to deliver something inside a milestone, pressure the engineer to deliver the right thing and understand that milestones are about gut checks and tracking. Give the people on the ground ownership for large scale features, let then see them through from start to end. Listen to your senior engineers, they've been through it before and they are going to give you as valid a read on the project state as any tracking tool.

The real solution though is fewer, more experienced people over a longer timeframe. Start with small teams, give them ownership and grow them as the resources are needed and can be used. If your a large company, start more projects, experiment, evaluate the projects regularly and kill the ones that aren't working out. The idea here is based on the model used by investors for every 10 projects you back your looking for 1 to make it big and cover the costs of the others.

The biggest problem I see with a setup like this is people quitting because their project is cancelled, but this is really about setting expectations, yes you'll loose some people but you'll attract just as many with the opportunity to own and contribute to something.