Manager In A Strange Land: Benchmarking, Part 2

Last column I talked about looking at exemplary companies and adopting their best practices. It just so happens I know a guy who works at an exemplary company, and he agreed to answer some questions. His name is Mick West, and he's been the technical director at Neversoft on all of the Tony Hawk titles. Here's what he has to say:

Jamie: Neversoft has consistently turned out top-rated games, on time, every time, for years. There are very few companies in the industry with that kind of track record. What's your secret? That is, of all the things you do, what do you think is the most important thing for making a great game on time?

Mick: I'd call it "game-driven development". It's easy to lose sight of what your final goal actually is. Neversoft went through some very hard times in our early years, where we were less focused. The key is to ensure that everything you do is focused on shipping a quality game on time. The quality of the code is a secondary consideration. The quality of the next game is a secondary consideration. The only thing that really matters is the game.

Jamie: On Tony Hawk 3 and 4, Neversoft didn't put in that much crunch time. How do you manage to avoid the big pushes, and what kinds of hours do people on the team normally work?

Mick: We work 9-7 Monday through Thursday, and 9-5 on Friday. About once a month we do a "Hardcore Week", where we work 9-9, but still 9-5 on Fridays. We never work on the weekends.

Working long hours is not the key to success. It is a symptom of failure. Ten hours a day is a very large amount of time. You just have to actually work those ten hours.

We avoid "crunch time" by realistic planning. We keep checking to see how far we've come, and how far we have to go. If something is not going to get done, then we just cut it.

Jamie: Where do you fall in the game design document holy war? How much design documentation do you guys write, and when?

We try to keep our up-front brief and to the point. The THUG design doc is about 20 pages, and it's more of an overview than a detailed design doc. We then just produce documents as needed over the entire lifetime of the project.

We've got a surprisingly large amount of documentation. It's a big game, and you can't develop something this size without a lot of docs. There's currently about 438 documents related to THUG on the network, and probably a few more scattered around. There stuff like cut-scene scripts, animation lists, QA checklists, level maps. Basically production documentation, rather than design documentation.

You've mentioned that Neversoft does "adaptive feature-driven scheduling". What is this, and how does it work?

Buzzwords are Huffman codes for language.

We don't really have a formal methodology that we apply to scheduling. It's just lightweight ad-hoc collection of habits that we've grown accustomed to, seem to work, and have been tempered in the fires of hell.

It's "adaptive" in that it changes in response to changes in the project environment, and it's "feature driven" as we always focus on actual, immediate, benefits to the project.

Basically, we just list the features that we want in the game (e.g., "animation blending", "environment mapping", "a level set in Paris", +10,000 others), and then take a guess as to how long they will take to develop, and balance that against how much it will improve the game. (For instance, "Is is worth implementing vertex animation if it will take Larry six weeks to do, and we'll only use it in this one cut-scene?") Then we continually refine the whole shebang until the game ships.

What software tools do you use for scheduling?

We do a broad overview in Excel, and we update it every month of so. Basically a per-person timeline with a granularity of about a week. It's never accurate, but it's still an essential tool in gauging progress, and getting broad overview of the work remaining.

Microsoft Project is impossible to use for this kind of thing. I've never heard of anyone using it successfully for a game project.

What's the team size been on the various Tony Hawk projects?

I think we started out with around ten people for THPS1, and now we've got around 50. The number of people has scaled fairly linearly with the size of the game. THUG is vastly more complex than THPS1

You guys don't use a lot of newfangled software engineering techniques, such as UML. What are some other "all the rage" software engineering practices that you guys don't do?

I read a LOT of books on software development methodologies. My favorite is Rapid Development by Steve McConnell (Author of Code Complete). It's a big, old fat book with a simple message: do what is appropriate.

There is no silver bullet, you have to use a rich mixture of techniques that suit the problems at hand. And more importantly, that suit the people at hand. UML is fine, but practically nobody at Neversoft has even heard of it, let alone could be comfortable using it. UML does NOT communicate if you don't know UML.

In fact, the vast majority of current software development methodologies might as well be non-existent to most programmers. Even your best programmers don't have the time to keep up on the latest "thinking" in this area, so you are just not going to find people who are familiar with concepts such as eXtreme Programming or Design Patterns. So fundamentally, we don't explicitly do ANY software engineering practice. Like our game design process, our coding practices are a collection of useful habits we've picked up along the way, refined and tempered by the fires of hell (using them on shipped projects).

______________________________________________________