I believe that people's time is the most critical resource in any software development project, and particularly for game development projects.
Time is required for two key processes in game development - Learning and Production. It takes a certain amount of time to learn what you need to know to perform a task, and it takes a certain amount of time to produce a feature. This applies to engineering tasks, design tasks and art tasks.
The keys to a successful development project are two fold. First, do the learning and production as quickly and efficiently as possible. Second, avoid wasted time.
A phased approach that allows simultaneous learning and production is critical for a creative environment such as video game development. Initial exploration should be done using protopyes, developed as rapidly as possible. This allows multiple paths to be investigated and iterated. Once a solid design and game play mechanics have been identified, the systems to support this can be finalized. Creating final systems before the game design and mechanics are determined is wasteful. However, rushing through the second part and using prototypes for production is at least as wasteful. Time should be well spent in both phases of development.
In some cases, such as a quick sequel on a mature platform, there is not a lot of learning required. We can take the learning from the previous game and development environment and go from there. However, I find this somewhat mind numbing, and prefer to work on new games and young platforms. In these cases a lot of learning goes on with the game development. A development environment that supports learning is important to rapid game development.
One of the best ways to learn is to do rapid prototyping. Merely studying a problem has some potential for learning, but can easily become navel gazing, rather than product development. Prototypes demonstrate capabilites to the programmer, and can be shown to the others on the team as well. A concrete prototype can be examined, and if judged adequate serves as a well defined specification for the final feature. If not, specific areas for improvement can be identified.
Getting prototypes completed as quickly as possible increases the amount of learning possible, and improves the final quality of the game project.
There are many models of software developoment that can be used successfully. I am willing to use any of a variety of models. The following has worked well for projects such as games that benefit from an agile model, due to the targets and goals shifting due to the needs of a creative process.
Phase 1: Analysis. Analysis is simply the process of gathering what we (the development team) already know about a feature. This should be a very rapid process in most cases, ranging from an hour for simple features to a half day for larger features.
Phase 2: Proof of concept. This is the creation of working code that demonstrates the critical portions of the feature. This phase uses methods that enhance the programmer's productivity. For example, fixed size arrays and parameters stored in global variables that can be changed in the debugger are reasonable techniques in this phase. Localization is probably not something to consider at this point, unless the feature is a localization tool.
Phase 3: Prototpye. This is an implementation that can be used by designers and artists to evaluate and tune the system. It will have data driven capability, so the values can be changed without requiring the programmer. The prototype must be robust, and fail gracefully when unsupported behaviors occur.
Phase 4: Production System. This is a general purpose implementation of the system, allowing all necessary changes and problem sets to be correctly handled. In a simple case, it may be a relatively minor improvement to the prototype, perhaps the addition of localization hooks. If the feature is key to the game, it may be expanded substantially from the prototype. Most of the code in a game should reach this level.
Phase 5: Library system. This is a generalized, multple use implementation of a system that is to be used in multiple games or applications. The system is as orthogonal as possible, meaning that all combinations of features work correctly together. For example, a locomotion system may support ground units (tanks), flying units (jets), and hover units (helicopters). A production system for a given game may not support hover units moving on the ground, as the specific game never requires it. However, a library system should support all variations as far as possible. Most code does not end up implemented at this level.