Hacker News new | comments | show | ask | jobs | submit login

The old post-mortems in Game Developer magazine were written almost in template form.

Went right: 1) Great team/culture 2) Everyone put forth the effort (scheduled crunch) 3) Some amazing techwork or artwork or designwork etc...

Went wrong: 1) Didn't anticipate x/y/z 2) Burnout (remember that crunch)? 3) Bad/lazy scheduling and/or capacity planning

Kudos to the people who did this at MS but you're looking at tainted data. Most game developers know what really went wrong and do not publicly broadcast it in fear of losing future contracts or publisher trust. In the end the postmortem becomes a soundboard for 'shoutouts' and cheer-leading instead of that raw, unbiased feedback.

I've been to all hands post-mortems that were like that and it can get really really ugly.

I've been to an all-hands post-mortem where the director of engineering had to say "anyone with an opinion besides [name of director of engineering] sucks"?

Said director of engineering literally watched us blow milestone after milestone yet somehow the knowledge we were going to miss our commits (and not by a little) never propagated upwards to the ceo. Either that or the ceo didn't want to listen; it could be any combination of those two.

Either way, the engineers were pissed.

Incredibly poor milestone management and a failure to triage didn't end up in our fucking learnings document somehow.

Exactly this. Only one game I've shipped had a Gamasutra postmortem but that one was so generic that it could have been applied to any other game, ignoring the specific issues that project had.

What are the real reasons for successes and failures? You left me hanging...

People making mistakes, of one type or another. In these post mortems though, they rarely attribute mistakes to any individual, or even team.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact