As the Fall release season begins, we are reminded of one of the truisms of our business: you can't postpone Christmas. Since most of us ultimately depend on those all-important holiday sales for our livelihoods, shipping product on time is even more important for game developers than for just about anyone else, in any industry.

Yet, the annual cascade of bad news has already begun. From the benign one- or two-week delays in shipment of Xbox and GameCube hardware to the far more troubling outright cancellation of SimsVille, game development projects routinely falter, stumble, or fail altogether.

It is impossible to overstate the financial, organizational and motivational damage inflicted by these disasters. Developers lose their jobs, or see the fruit of their long nights of crunch overtime shelved and forgotten. Publishers lose fortunes as advertising money is spent in vain. Companies go out of business.

The common alternative, shipping games on time but riddled with bugs, is hardly more exciting.

As Steve McConnell writes in his must-read book, Software Project Survival Guide (ISBN: 1-57231-621-7), our plight is hardly uncommon:

McConnell's name is well-known among software engineers. He is the author of several best-practices books, including Rapid Development, Code Complete and After The Gold Rush. Software Project Survival Guide is one of the shortest and easiest to digest of the lot; managers, designers, artists and other non-technical readers can breeze through it in a week-end and come out of the experience transformed.

In a nutshell, McConnell states that lack of formal methodology, unrealistic expectations and inadequate corporate practices are the (entirely preventable) causes of most software project failures and delays. And while McConnell writes for the software industry at large, all three of these weaknesses are glaring in our corner of the world.

Fortunately, this is a disease that we can cure.

As the old saying goes, life is what happens while we're busy elsewhere. Thus, the prudent developer thinks defensively, planning where planning is possible, and securing safety margins where it is not.

However, we in the game development business tend to define schedules in an overly optimistic fashion. We look at the calendar, see when the game must ship in order to be on the shelves by Thanksgiving, and set whatever milestones will allow us to meet the deadline - on paper. If that means assuming that the office network will always work without a glitch, or that we can suddenly hire 6 senior artists in the middle of summer, or that the entire staff will be able to work non-stop overtime for 5 months, so be it. Then, if we estimate that a certain milestone is only 90% complete on the day it is supposed to be signed off, we roll up our sleeves (those of us who wear sleeves, anyway) and work harder to make up the difference before the next deadline comes along.

This strategy works fine - if everything goes well. (When does that ever happen?) Otherwise, small delays and inefficiencies may pile up until we realize, six weeks before we're scheduled to turn gold, that we can't finish the game in less than four months.

To prevent the insidious creeping-in of unseen delays, McConnell suggests defining "binary milestones", i.e., sets of tasks that must be considered either completely finished or not done at all. His reasoning is sound, because estimating levels of completion is a difficult and imprecise process. For example, saying that the AI is 75% done is nearly meaningless, because the last 25% of the work will probably take more than 25% of the effort. Besides, just like a submarine that is 90% seaworthy is 100% worthless, a game that wipes out only 1% of hard drives isn't exactly 99% ready for release.

Similarly, schedules must take into account the fact that people need vacation, sick days and training, and that they can't work at peak efficiency under pressure on a long-term basis. If a project can make money only if it can be completed by a team of 8 working 60 hours a week for 9 months, then it probably shouldn't be attempted, because the odds of the entire team making it through the project without a serious breakdown are infinitesimal.

Finally, since we must protect ourselves from circumstances outside our control, the game should be in a shippable form all the time. Development of new features should be scheduled so that a solid, consistent build can be produced every week or two. This way, if the project runs late but the shipping date can't be moved, we can sacrifice the last few bits of content and sell a product that, while not quite as elaborate as we would have wanted, is still finished and complete.

It boggles the mind that some teams still attempt to make do without a detailed, thoroughly reviewed design document. Here are a few eye-popping quotes from McConnell's book:

"Researchers have found that an error inserted into the project stream early - for example, an error in requirements specification or architecture - tends to cost 50 to 200 times as much to correct late in the project as it does to correct close to the point where it was originally put into the stream." (Emphasis added.)

Distribute your design documents as widely as commercial reason allows, and ask for thorough critiques. We designers are human beings, and it is hard for us to see the flaws in our concepts. A fully-functional prototype allowing the design team (as well as potential customers) to test the gameplay must also be delivered very early in the project; waiting until final QA to check whether the players have fun is just too risky.

If we catch design flaws while the project is still at the paper or prototype stage, we will save ourselves untold amounts of grief compared to the worst case - finding out, a year or more into development, that the game we have crafted isn't fun. Don't think that you are immune to this doomsday scenario: according to the press coverage, this is exactly what happened to the SimsVille team, and the folks at Maxis are not exactly amateurs.

Finally, the design document, the software architecture and the schedule must all be carefully maintained throughout the project. Any non-trivial change to the specifications should be submitted to a formal approval process, to insure against duplication of work and incompatibilities.

Game developers are notoriously resistant to management. After all, we chose to develop games because the "real world" stifles creativity, enforces pointless rules, and prevents most people (especially the young) from making any sort of significant contribution. Plus, a majority of our lead programmers and artists have neither training in, nor interest for, management: They are merely put in charge of a team because of their expertise, and expected to lead by example. Sometimes, this works fine; if it doesn't in your company, maybe you should consider an alternative. As McConnell says:

The person in charge of the programming team doesn't necessarily have to be the best programmer of the bunch. She must be competent, of course, but must also be able to deal with schedules, negotiate with the art and design teams, coach the rookies, etc. If your technical wizard prefers to work alone, let him do so, and assign the team coordination tasks to someone else. Everyone will be happier and more productive this way - provided, of course, that the company's salary structure doesn't over-compensate managerial duties in comparison to other jobs. If that is the case, there is a good chance that people will go after management positions even if they are ill-suited for them, just because it is the only way to increase their incomes. Obviously, this situation must be prevented. Many large, successful companies in the high tech industry now have "technical advisers" or "core competency specialists", who make as much money as division managers and vice-presidents despite having no line management responsibilities whatsoever, because their contributions to the company as a whole are just as valuable. This may be the ideal compromise.

An appropriate, carefully planned set of corporate practices can also increase both happiness and productivity. For example, McConnell notes:

"Studies have found that productivity levels of developers who work in private, quiet, one- or two-person offices can be as much as 2.5 times as great [as that of cubicle-dwellers]."

Achieving peak productivity on a constant basis may require an investment in physical space, training, specialized talent, etc., that companies are often afraid to make because of the short-term costs. But the long-term benefits may be worth the trouble.

Sure, no process can guarantee perfect results. The carefully laid plans of mice and men can still go wrong, no matter what we do. Still, careful preparation, reviews and proper management practices may save a lot of grief at best, and give us a chance to learn from our mistakes at worst.

Take a look at a couple of post mortems in Game Developer magazine, and you will see that the "What Went Wrong" section will mention the same problems over and over again. It doesn't have to be this way. It can't keep on being this way.

Not if we want to prevent another SimsVille.

Editor's Note: Software Project Survival Guide is available on Amazon.com by clicking here