The last few years it has become a lot more popular to think about process in game development land, doubtlessly caused by lessons painfully learned in train-wrecked projects and a dawning realization that even our brethren (and sisthren) from the non-entertainment software industry are doing it. However, wearing a T-shirt saying "yay process" and reading Steve McConnell before bedtime is not enough. It is easy to succumb to Magic Bullet Syndrome and figure that, as long as you do everything Kent Beck says, you'll be alright. In other words, it is easy to stop thinking about what is really going on. I speak of course from experience.

I was recently reminded of the limits of process when I read an interview with Maryam Mohit from Amazon.com on Good Experience, a website "monitoring the online customer experience". About Ms Maryam:

Maryam Mohit started working at Amazon.com in 1996 and soon after became Amazon.com's V.P. of Site Development, with responsibility for the online customer experience. More recently, since returning from maternity leave, she is in charge of reviewing the UI of new developments on the site.

I found the whole interview interesting, but the one key bit for me was this:

Q: But you need the right structure within the organization to get you those e-mails [about a new feature] from customers. I'd disagree with you there. You don't need an organization structured so the e-mails get to product developers, but rather product developers who care enough to go and get those e-mails. At Amazon.com we started out with people who cared enough to go get the information they needed. Now that we're bigger, we need those structures and processes. But organization is no substitute for passion. If the people aren't passionate about the right things, your organization doesn't matter.

I am not trying to argue for passion over process here. Process has its place. However, it is easy to misapply. It is easy to select or design the wrong process for the people who will execute it and the goal they are trying to achieve. And process by itself does not magically change people.

I do not have an easy answer about how much or what kind of process is right or wrong. The rule of thumb I would like to apply the next time I need to make a decision about process is: Process should make you do the things you might forget in the heat of battle, and nothing more. When you're in the middle of a project, you may be tempted to not write that meeting report and not ask everyone's opinion on some decision. But during the post-mortem, if not before, you will realize you should have done so. The problem is, the next time you're in the thick of things, when your eyes are fixed on the next milestone and not on the long run, you will probably make the same mistake again. I know I have. Codifying this knowledge in a process and then sticking to it is, I believe, the best way to avoid this problem.

Designing and executing a process is, of course, another story.