Fog Creek Software
Discussion Board

Project Management on the XBox

There's an interesting talk on MP3 over at Dr Dobbs from one of the insiders of the XBox.
Covers milestones, source control, deadlines and things.

Matthew Lock
Sunday, March 31, 2002

That was a very good lecture.  Very little that isn't available elsewhere, but very much that most companies never care to think about.

I hate how it's a streaming lecture from DDJ (even Cringely knows to make it downloadable damnit, so people can mirror it on Gnutella), and I wished I had a transcript so I could gloss over points I knew.  So since I type well, here's a quick outline for anyone interested, with rough timestamps.  I only listened once, so YMMV.


A snapshot of Windows was made and stripped down heavily, to serve as the OS.  The goal of the system's mem footprint was 1MB, and they beat it by nearly an order of magnitude, 150K.  The lessons were:  1) use old stable shit, 2) set goals, 3) exploit the features of a fixed system, so you can strip out unnecessary features, as well as easily optimize.  (5:45)

Standard template for all specwriters was used.  It included items like localization and security; things one would normally forget.  Forces spec writers to confront these items when designing new features. (8:30)

Through the project, spec writing fell off, and newcomers to the project could no longer rely on them.  New project docs couldn't rely on the specs.  Life commenced to suck.  (9:00)

Made sure to talk with game developers, recognizing them as a "customer."  The XBox team switched to a different execution environment than Windows programs normally used, because performance and predictability were the priorities for game developers.  The lesson was that it was important to talk with target demographics.  (10:00)

Using the DirectX API was a double-edged sword.  While it was familiar for game developers, the XBox team completely changed the backend while keeping the same API signature.  MSFT didn't communicate the different performance characteristics to the game developers, which really pissed them off.  The lesson from this misstep was that consistency, or at least good change docs, rules.  Consistency should not be allowed to be misleading.  (12:00)

Use CVS.  Let a wide audience (testers, mgmnt) have access to the checkins, so everyone knows what's going on.  Things like branching are very important.  (14:00)

Asserts rule, catches bugs early on.  In the SDK they took up more code than game code.  Great for game developers too, since they're getting a lot of debug and documentation for free.  For example, a game developer could see that a parameter she used was invalid while linking into the SDK's debug version.  (16:00)

Use a bug tracker, with priorities and schedules.  Nondevelopers must close bugs, not the developer, because developers are rarely the best people to do so.  MSFT peons use the bugtracking system to track many things like work items, documentation issues, etc.  Use early & often.  (17:30)

Used monthly milestone releases rigorously -- #1 reason for shipping on time with no bugs.  Forced people to prioritize early on, as well as streamlined many processes.  Useful for all companies even if they're just internal releases.  For example, the install program had to be made early, which most people put off 'till the end of development.  Therefore it was very stable.  Also, there were no strange hiccups in sending the program to be mastered onto CD.  (19:15)

On the system team, 1st 3 weeks per month was open cvs checkin.  "Lockdown" occurred on the final week.  During lockdown, the "War Team" at MSFT must decide what gets checked into cvs, which is composed of key project people of all sorts (testers, devs, management -- artists & producers in a gaming company artists would also be included).  (22:00)

This release schedule allowed people to figure out what features could be thrown out, as well as what new things needed to be added.  Trimming features down to a realistic subset is an important component for shipping on time.  (24:00)

MSFT uses about 1 tester per developer.  The spec is written for a feature, a developer is assigned to code it, and a tester is assigned to write the test plan for it.  The tester's plans & test code are all in place once the developer is ready.  The testers usually write more code than the developer.  While some testers don't need to write code, like gamers, most testers should be able to.  (25:15)

Everyday at 4am, daily builds run after wiping the HDs of the designated build machines.  (In the online team, if you break a build, an actual toilet is sent to your office.)  Then build verification tests ("smoke tests") are executed, which are very minimal tests to see if the build runs.  Stress tests go next.  Emails go out to the team after each of these stages.  (26:30)

(About hardware)  Anecdote about failing to usability-test world market:  MSFT failed to usability-test controllers for the Japanese market, which the Japanese thought felt too big in the hand, and the XBox team had to scramble to refactor a new one for that market.  (28:20)

It was important to spend time researching for preexisting stable tools, including at the beginning of the project.  Teams should plan for spending that time.  (31:00)

(About designing for XBox) XBox audio can do all sorts of whoopass things in hardware that you can't on other systems.  (32:00)

(About designing for XBox) The graphx rule too.  Experiment with it, dammit.  (37:00)

Usability testing -- the XBox team didn't plan for the "30% German rule" when building the Dashboard.  German text is usually 30% larger, and they had to really refactor the Dashboard.  Use Unicode early on.  Don't be locked into US standard framerates.  (40:00)

"I'm playing a video for the audience, that sounds totally mentally impaired if you're hearing only the audio."  (43:30)

(Q&A) The XBox team didn't use Visual SourceSafe because it blew.  Instead they used an internal tool similar to Perforce, which the speaker recommended highly.  (48:00)

(Q&A had other, boring questions...)

(Q&A) Q: Who's the unlucky schmoe who carries the toilet over to your office, if you break the build?  A: You.  (53:00)

Monday, April 1, 2002

If you don't want to stream the talk it can be downloaded from here:

Matthew Lock
Monday, April 1, 2002

I wonder why Microsoft chose to used a stripped-down XP kernel instead of using Windows CE. The Sega Dreamcast used Windows CE and DirectX. Why did Microsoft think their own Windows CE was too wimpy for their own game machine? The Dreamcast was not a commercial hit, but it didn't seem to have any serious technical problems. The XBox team had to do a lot of work to roll their own XP kernel while Windows CE is already designed in a modular fashion for exactly this purpose..

Banana Fred
Monday, April 1, 2002

Dreamcast developers had the option of using CE, but most developers decided to go straight to the metal.  The few CE games performed poorly.

Monday, April 1, 2002

I got the impression from the lecture that it really didn't matter.  They just wanted a stable kernel they could gut.  Just like using a linux or bsd kernel and surrounding it with support tools that assume nothing is running in user-mode.

Richard J.
Tuesday, April 2, 2002

Given that XP Embedded is a product now, with a modular set of options, I'm guessing that the work to produce the XBox kernel wasn't done in isolation. But that's just a guess.

Mike Gunderloy
Tuesday, April 2, 2002

From listening to the lecture it sounded as if much less than an embedded kernel was left after they'd finished, possibly no more than a thread dispatcher and HAL.

Simon Lucy
Tuesday, April 2, 2002

*  Recent Topics

*  Fog Creek Home