Live data from Hacker News

“What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

research.microsoft.com

1–10 of 52 posts

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#3
> 9. CONCLUSIONS

>

> We find that we were able to identify both best practices and pitfalls in game development using the information present in the postmortems. Such information on the development of all kinds of software would be highly useful too. Therefore we urge the research community to provide a forum where postmortems on general software development can be presented, and practitioners to report their retrospective thoughts in a postmortem.

>

> Finally, based on our analysis of the data we collected, we make a few recommendations to game developers. First, be sure to practice good risk management techniques. This will help avoid some of the adverse effects of obstacles that you may encounter during development. Second, prescribe to an iterative development process, and utilize prototypes as a method of proving features and concepts before committing them to your design. Third, don't be overly ambitious in your design. Be reasonable, and take into account your schedule and budget before adding something to your design. Building off of that, don't be overly optimistic with your scheduling. If you make an estimate that initially feels optimistic to you, don't give that estimate to your stakeholders. Revisit and reassess your design to form a better estimation.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#6
post #4

The recommendations at the end of the pdf seem to be written by captain Obvious. They are so generic they can apply to about ANY project even non gamedev related.

>The recommendations at the end of the pdf seem to be written by captain Obvious.

Doesn't that simply mean that this research confirms other people's experience/gut feeling?

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#8
post #3

> 9. CONCLUSIONS > > We find that we were able to identify both best practices and pitfalls in game development using the information present in the postmortems. Such information on the development of all kinds of software would be highly useful too. Therefore we urge the research community to provide a forum where postmortems on general software development can be presented, and practitioners to report their retrosp…

There's some world-shaking insight.

The best piece of advice I can give is to never, ever give an estimate to stakeholders until you've worked on the estimate first. And don't finish an estimate until you've actually built some small proofs of concept.

Your estimates will still be wrong, but they'll be much more accurate than some off-the-cuff number that your stakeholders will be building their various plans around.

It all sounds straightforward, but the hardest discipline for me as a developer is to keep from saying things in stakeholder meetings that make my stakeholders happy in the moment, but ultimately needed more thought and effort. It's something I struggle with in every such meeting, to varying degrees of success.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#9
post #4

The recommendations at the end of the pdf seem to be written by captain Obvious. They are so generic they can apply to about ANY project even non gamedev related.

Well they weren't that obvious to 155 projects it seems...

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#10
post #8
post #3

> 9. CONCLUSIONS > > We find that we were able to identify both best practices and pitfalls in game development using the information present in the postmortems. Such information on the development of all kinds of software would be highly useful too. Therefore we urge the research community to provide a forum where postmortems on general software development can be presented, and practitioners to report their retrosp…

There's some world-shaking insight. The best piece of advice I can give is to never, ever give an estimate to stakeholders until you've worked on the estimate first. And don't finish an estimate until you've actually built some small proofs of concept. Your estimates will still be wrong, but they'll be much more accurate than some off-the-cuff number that your stakeholders will be building their various plans around.…

I think this is a symptom of a fear of "I don't know." If I could change one thing in dev cultures, I would instill a healthy respect for the sentence:

"I don't know, but here's $how_I'll_find_out and here's $when_I'll_have_an_answer."

Post reply on HN