Oh, and we would be remiss if we didn't point out that next door to the "Official" gamedev.net hotel, the Day's Inn, was the local headquarters of the Church of Scientology. It was the source of endless jokes, as we passed it every day on our way to the GDC bus. Despite the posters outside, we didn't take 'em up on the offer for the "free personality assessment". We already know we're jerks, so there's no point.

Tucked away on the morning of day five was the programming keynote speech by Dr. Frederick Brooks, professor of computer science at North Carolina University and author of the book The Mythical Man-Month. In addition to starting the Computer Science/Computer Architecture departments at UNC in the 1950's (which was a pretty impressive feat given that the terms "Computer Science" and "Computer Architecture" didn't even exist then) he was one of the original designers of the IBM System/370 hardware and OS in the 1960's. Despite having no previous template upon which to design their CPU and OS, they created a system that is still (in a much-evolved form) operational and available for purchase today. Imagine designing an OS having never actually seen one, and you get the idea.

In any case, Dr Brooks' lecture was about how to properly staff your team and design your software systems early on so that your project doesn't descend into chaos later. He showed the clear difference between one-person projects, two-person projects, "small projects" of less than 20 people, and "large projects" of over 20 people (at one point, the System/370 team had 1,000 members, but he doesn't recommend such a size for a team anymore). The take-home advice seemed to be:

• Make your specs very very specific. If they are vague, everyone will read into them what they think it should look like, and nobody will have the same idea. Specs that are very specific and wrong are preferable to specs that are vague, as wrong specs can be discussed and corrected.
• Borrow a hint from moviemaking and have both a producer and a director. The producer's job is to ensure that the overall vision is in-place and the director's job is to make sure that day-to-day operations are working towards that vision.
• Try to pair people off, because programmers working in pairs are more than twice as productive as programmers working singly. The amount of code produced at a stretch isn't as high, but the number of defects written is far far lower, and the result is a net gain over working singly.
• Games are very hard to test compared to things like batch systems that are relatively easy. Make allowances for lots of testing.
• Have your source control and such in place before you start. Waiting until you need it won't work.

Today is the last day of the GDC 2003, and it shows. Booths in the expo are packing up, final contacts are being made, the press room is dwindling, and the lectures are diminishing. We're all pretty tired (possibly because of the parties last night), but it was definitely an experience and tons of fun.

More updates will be coming throughout the next few days, but in the meantime, see you next year!