

Big productions: Why 'Fail Early, Fail Often' Is The Wrong Approach - pushingbits
http://www.gamasutra.com/view/news/26105/Assassins_Creed_2s_Plourde_On_Why_Fail_Early_Fail_Often_Is_The_Wrong_Approach.php

======
kristiandupont
It's "release early, release often" but I guess it doesn't matter much.

Speaking as a former founder of a video games company, I think that this kind
of thinking is inherent to the entire industry and it is killing it. The
inspiration clearly comes from the movie industry where admittedly, you don't
make a movie in small iterations. As it stands now, triple-A titles have to
make it to the top ten to be profitable due to extreme development costs which
drives up marketing prices which in turn drives up the price of the games to
the consumer. This spiral is really bad for the industry. I think that indie
and small developers will take over most of the market because they do much
smaller and more frequent releases.

~~~
jim-greer
How exactly are you supposed to "release early, release often" when you're
shipping DVDs to tens of thousands of retail locations? After going through
months and months of Microsoft/Sony/Nintendo certification on a 3-ring binder
full of technical requirements? And having the ESRB play every level of your
game to make sure it doesn't have boobs or entrails?

Not to mention that for every programmer on these games there are 5 to 10
artists and level designers cranking out content. There's no automated
regression suite to make sure that your last minute physics tweak didn't break
one puzzle in one level somewhere.

There's a reason that console developers have miserable lives - they have huge
teams and launch dates that are very expensive to move.

I'm not saying that things couldn't be done better, but it's a fundamentally
hard problem.

~~~
teamonkey
Hence the qualifier about indie and small devs, I imagine.

------
forensic
Are there AAA game devs with 300 person teams who really think they can win
without thorough documentation? WTF?

"Release early, release often" is for webapps and small teams. When you're
dealing with a AAA game there is such a huge network effect it's actually
crucial to make the first release a good release. You then get all the word-
of-mouth which drives the game industry. Most AAA titles that ship with bugs
pay for it dearly in sales because gamers talk to each other and word gets out
in a few days about just how finished the game is.

"Release early, release often" can't possibly apply to AAA games with 300
person teams and fixed launch dates.

~~~
steveklabnik
But it can apply to their internal dev process, where they 'release' to their
testers and other stakeholders all the time.

------
Quarrelsome
Yea, waterfall works if you do it properly. Is that so surprising?

~~~
steveklabnik
Yep. Console games have different requirements than other projects, so
waterfall actually kind of works. Your hardware isn't changing, you end up
with a single, static product, your requirements can be known ahead of time...

------
eswat
Didn't Plourde just dive into 'Fail Early, Fail Often' with the way they did
documentation?

------
diN0bot
i think there are salient advantages to preferring to fail over documentation
---which is about getting the implementation right before time-consuming bugs
or poor code are introduced--and preferring to "fail fast"---which is about
not investing in a product the market doesn't support.

------
dhyasama
He advocates moving failures upstream to the design process because it is
cheaper than failing during the development process. While that is true, it's
not an either or proposition. There is no reason you can't fail early and
often in each stage of the process.

