Feature Creep

Is it fair to describe feature creep in videogames development as "feature creep"?

Is it more the case that it reflects videogames development as a creative process involving uncertainty and discovery?

It'd be interesting to measure how many features get added by "feature creep" at each stage of development of a game and feature, as a proxy measure of much uncertainty is present in the current project plans.

Inappropriate error checking

One interesting anti-pattern I've come across lately is the whole issue of peppering run-time code with things like: if(index >= count), return. Typically this is added to engines to make them more "user friendly", "robust" or "general".

What's wrong with this? Typically, the data that this condition is operating on is a static asset that has been pre-processed by a tool. We're using an expensive run-time check, often for every frame that we do something, to check a static condition that should be done at asset load or compilation time.

Code that can tolerate erroneous data breeds erroneous data. Erroneous data breeds over complicated code. And that is a maintenance and QA nightmare.

Sometimes you just need to throw bad data out as unacceptable. That's actually the most friendly, robust or defensive thing to do.

Games project management is interesting.

We focus so heavily on process. We focus on defining tasks, ordering them, estimating the time required and achieving a smooth production with balanced resources.

Yet we never take explicit account of the nature of our industry in our management methodologies. We work in a creative industry, yet none of our current management methodologies address this explicitly, usually only indirectly or tangentially.

Creativity is not a mystical process. There is a big body of literature out there discussing its origins, various models for it, how to encourage it and how to manage it.

Consider some of the main concepts in creativity:

* Divergence

* Convergence

* Incubation

Divergence and convergence are complementary processes. Divergence consists of generating new approaches, alternatives, ideas and plans of action. Convergence involves evaluating those options to select the most appropriate to achieve a solution.

So, to use creativity to solve a problem, we need to identify and define the problem, consider it from many perspectives and reframe it so that we fully understand it. We then diverge to generate many possible solutions, then converge on a sensible solution. And implement it.

The candidate solutions may not be immediately apparent. We may require time to consider the data before we can offer a solution. This is incubation. This is the idea that we need to allow our unconscious thought processes time to work on a problem, before an idea for a solution bubbles to the surface. Our unconscious thought processes are capable of solving far more complex problems that rational thought alone can solve.

So, returning to the idea of games project management, it's strange that we don't manage our projects in a way that supports these concepts. Typically, when a task is begun that requires creativity to solve or implement it, a developer may struggle to make real progress for the first few days, either "spinning his wheels", or attempting solutions that may turn out to be ineffective. What is happening here?

Our management methodologies haven't facilitated the creative process. When a developer "spins his wheels" for the first few days on a task, that is because we haven't given him time for incubation; we haven't allowed time for his mind to chew over the task and to produce ideas for solutions. Instead, he spends the first few days of a task gathering data and incubating solutions. How much time could we save if we factored in some time for incubation? Instead of simply assigning a task to a developer, we can have a phased commencement, where before implementation is begun, we give the developer the opportunity to fully explore the problem before work begins so they can develop ideas ahead of time. The developer will then be likely to begin the task with clear plans for implementation in mind.

What of the process of attempting solutions, only to discard them? This could simply be an example of experimentation. Experimentation, and learning from the failure of those experiments are key to both creativity and learning. Alternatively, however, this could be an example of insufficient divergence or premature convergence.

If we fail to generate sufficient options for a solution (insufficient divergence), we clearly may overlook a more effective solution. When we reach development, we find none of our options suffice. We then have to either adapt our solution, which may or may not prove ultimately effective, or enter a new divergence and convergence iteration. If our management process had facilitated the divergence process, and given it sufficient time, perhaps we could save time down the line on repeating those processes at a more expensive stage of development.

Premature convergence is the selection of a solution before all solutions have been fully evaluated, with the consequence that a superior solution may be overlooked. Again, this may result in significant adaptation or rework of a solution that proves ineffective, typically at the expensive, implementation stage. Better, explicit management of the convergence stage, ensuring all perspectives are considered, all stakeholders' needs are addressed and the full feasibility of a solution is evaluated could save expensive implementation time.

Creativity offers a new, interesting and potentially productive perspective on the management of games projects.

I have a theory about the nature of games development. Of what differentiates it from other software development effots.

Simply put, I think the difference is the domain for which we are developing software. Most mainstream software development efforts entail developing software for a relatively fixed, external, real-world domain. In games development we are faced with the challenge of developing a piece of software for a domain that we construct or invent ourselves. A domain that we're constantly changing and evolving. A domain with few, fixed, real-world anchor points.

Consider the example of an FPS. The IP and game design for a given FPS defines the domain in which the software must be implemented. It defines the rules of the world of the game. It defines the mechanics of gameplay. It defines the look of the game. It is unique to each title; it cannot be shared or re-used. The genre, technology, market and so on may influence or constrain a particular IP, but it remains something very open and flexible. We can conceivably invent any possible game design and therefore domain for our software to exist within.

Of course, the game design evolves throughout pre-production and production. The software is therefore being implemented in a domain that is changing. What makes this process particularly difficult, is that this is not a domain that is rooted in some kind of external, absolute, objective real-world situation. The game design - and therefore the domain that our software is modelling - stems from a human, creative process.

Typically, this design is a group effort, a socially constructed shared vision. So, in addition to attempting to build software within a subjective, changing, human design, we need to consider the issues of communication and knowledge transfer. A game design is a shared vision; how can we be sure all members of a team share the same vision? How can we be sure it is accurately communicated? How can we know that implementation specific considerations that may constrain an implementation are fed back to the design process and reflected within the game design?

The game itself is not the only piece of software we create during development, of course. We typically also develop tools, editors or server infrastructure. Software is a socio-technical system, comprising both a human and technical component. The technical component is of course the software and supporting tools we develop during the project. The social, human aspect is the team, the team's shared vision and development processes used.

So, we are attempting to construct a socio-technical system to implement a game in an evolving, creative, invented domain. No wonder its challenging!