

What Went Wrong? Learning From Past Game Development Postmortems - ConradHex
http://www.gamasutra.com/view/feature/4001/what_went_wrong_learning_from_.php

======
JabavuAdams
Anecdote:

I'm sitting in an all-hands meeting at a 20-ish person game company I'm
working for. We've just had a project canceled. We go around the table doing a
post-mortem.

When it comes to the producer's turn, he pulls out a Game Developer mag, with
a post-mortem of a previous project we shipped. We repeated almost all of the
"what went wrong" section.

Of course, it didn't seem that way, in the thick of things.

OTOH, I used to be a bit of a process evangelist. I read Steve McConnell and
Joel before they were popular. It's easy to single out unsuccessful projects
and point to all the mistakes they made, but often the successful ones make
exactly the same mistakes.

There's a moment in the middle of a project when it seems like everything's
going wrong, and the constraints are unsatisfiable, and it'll just end in
disaster. What you do at that moment can make all the difference. Sometimes
just refusing to concede the obvious is enough. Often, it's not.

Even much-admired companies like Pixar have their crunch horror stories.

------
stcredzero
"Another classic error we committed was trying to develop generic tools with a
view to possible future productions, rather than tools dedicated to the
experience of the game we wanted to create."

I wonder if there's a lesson here for programming languages? Kernihan and
Ritchie developed C for their needs of the moment (Implementing SpaceWar on a
PDP-11) and it became wildly successful as a language. Maybe feedback from
actual use generally trumps design up-front for languages?

~~~
gcv
There's a lesson here for everything.

Projects where the tools and frameworks are designed solely for the problems
at hand get burned because the specifications change (see point 1 in the
original article), and the tools are not flexible enough for the new
requirements. Projects where the tools are flexible end up burned either: (1)
because the tools are not flexible enough, and therefore suck, (2) because the
tools took too long to develop, and project work never got done, or (3)
because the tools were too flexible for the programming team which ended up
abusing them and writing unmaintainable code.

It may be a tough pill to swallow, but projects succeed and fail because of
the people. Not because of procedures, but solely because of the people.
Talented, determined, bright people will find a way to ship a product, will
work their way out of any mess. Depending on the project, and depending on
luck, the required degree of talent, determination, and intelligence varies.
No matter how much the "project management" industry wants to sell books and
classes and software, everything comes down to brainpower.

------
jcl
I've wondered about the usefulness of the "what went wrong" section of the
Game Developer postmortems, given that they are all games that _actually
shipped_. It's possible that the "what went wrong" problems are things that
might have jeopardized the project had they been worse. But it's also possible
that these problems are simply aspects of successful projects, and that trying
to fix them would make the project less likely to succeed.

For example, a lot of postmortems complain about not spending enough time
creating artist tools. Does this mean spending a lot of time on tools will
make your project more successful? Or does it mean that all the teams that
spent enough time on tools didn't have enough resources to complete their
projects (and thus didn't get postmortems)?

~~~
jcl
Or another possibility, which only just occurs to me: Some of these problems
are going to be problems on any project, successful or not. So if a project
has no major problems, these are the ones that will be mentioned -- Game
Developer postmortems require 5 pros and 5 cons.

It's like how you'll rarely hear of a software project that is refactored
enough, documented enough, or that has a user interface that everyone is happy
with. You could probably spend an entire project's time on artist tools, and
they would _still_ be an issue for someone.

