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

I would argue that crunch is at the root of good software development practices.

I've spent time in the industry and its behind in practices, wages and quality of life. There may be some smart, motivated people but the industry as a whole has not grown well.

Exactly right. Too often I've seen people commit to a schedule where the milestones were of unknown difficulty. When cutting through a new jungle, you have no idea what is between you and your goal, so really all you can say is that the best you can hope for is X if this jungle happens to be like previous ones.

This is especially true in startup situations where you are learning technologies that may themselves not be complete, with people who are learning their own new things, to achieve a result which is only hypothetically possible. It drove my CFO nuts but rather than commit to a schedule for a big deliverable I would walk backwards from the end point and say, "These are the stops between where we are, and where we are going. We measure our progress by getting to each stop, but like a subway map there isn't a known amount of time between stops, only what the stops are." And he would come back with "well we only have money to get to this date, will it be done by then?" and then we would talk about the uncertainty between each of the milestones. At some point you can reach a common understanding of what the unknowns are and how discovering their value will inform on the difficulty of the next step.

That said, I've met managers who just say "Oh we will be done by %x date." and then basically worked the problem the same way I have.

If you're agile you can break down the intermediate stops as sprints but estimating the backlog is still the killer step.

TDD might not apply well to games because they are used by big corporations for 15 or 20 years. It makes more sense when you're working with old legacy code and you want to add features to it. Unit tests are definitely not a all-around solution but they have their use cases.

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.

Something about your last paragraph rubbed me the wrong way. Sorry.

> about 10X the competition

Steam added 1500 games in the first 7 months of 2015. Crunchbase had over 8000 investments in 2015. So I don't think that's true, even accounting for a Christmas peak.

> juggling massive game assets

Lots of data goes into games, lots of data comes out of websites. The difference to my eyes is that the industry has multiple, principled, well-understood frameworks to deal with the data problem and the games industry has...what? Maybe the state of the art has moved on in the last 5 years but when I left it was all "well it's just a DAG, how hard can it be to write a tool to recursively build it".

> a fraction of the budget, finance, and exit options

Being willing to work for less and with fewer resources is not a sign of good engineering practice. I don't know if I'd say it's the opposite but it's at best irrelevant.

> a tough frame rate budget

Not very different to needing to meet tough latency/error rate SLAs, except instead of failing TRC (or getting your exec producer to stare down MSFT/Sony), you'll just go broke. Oh, and you don't know what the SLA is, ever, so it's a continuous process of tradeoff.

> all issues GPU-ish (when was the last time you wrote a shader, Mr. Website Developer?)

Ignoring that some "website developers" (many of whom are not "Mr" - something else that the games industry does not do well at) do write shaders in the form of GPGPU optimization of ML tasks, obviously tasks differ. Let's not pretend that banging out something in Cg is PhD-level shit. It's not harder than writing a Spark job, for sure.

> having people with a huge range of technical skills requiring direct access to the source/asset repo.

You have Mr. Blow upthread sneering at Twitter for employing 4000 people to build something "trivial" but you think that each of those people have identical programming chops in every bit of the code they touch? If there's a single thing that argues against your idea it's this - the rest of the industry has become pretty good at modularizing areas of the business and auditing changes to it with code review, build/asset/deployment tagging etc. The last games company I worked at, someone stayed at the office until 5am before going on holiday for a week and sent an email that effectively said "I've rewritten quite a bit of the engine, you'll probably need to fix the build because I didn't test anything, see you in a fortnight". People gasp when gmail/twitter/facebook is down for half an hour but I've worked in places where there _wasn't even a canonical build_ that could be broken.