T w e n t y S i d e d

Last week I derided permacrunch – the policy of working an entire creative team 70 hours a week all the time – as “the policy of simpletons and sociopaths”. This led to some people asking, “Why is crunch even a thing?” Can’t management just plan the schedule so that the project is done on time using only 40 hour work weeks?

Sadly, I don’t think that’s a fair expectation at all. And it’s not because management is a bunch of soulless meanies who want to work our poor developers to deathI mean, management might still be soulless meanies, but not for this reason.. The problem is twofold:

1. Scheduling is hard. To accurately predict how long it will take you to create software, you’ll need to know all the problems you’ll encounter ahead of time, and how long it will take to solve them. By the time you know that, the game has probably shipped.
2. There’s no upper limit on how much time you can spend making a game, and no matter how much time you give the team, some developers will always push for “just one more feature”. Not because they’re stupid or irresponsible, but because they really love games and want to make this one really good. I say this from experience. Good Robot shipped about four months later than we planned, because we had more features we wanted to add. And none of us were getting paid until the game was done. If we were willing to delay our own payday to make the game we wanted, how much easier do you think it is to push for more features when you’re not the one who will have to bear the direct financial consequences?

Scheduling isn’t just a problem in videogames. It happens in all kinds of software development. When asked “How long will it take to accomplish X?” the most common answer will be given under the assumption that when you work on X you’ll never encounter hard-to-identify bugs, that the requirements of X won’t change, and that some obscure hardware problem won’t eat up a bunch of your time. It assumes you won’t have staff turnover that requires integrating someone new to the project. It assumes that no programmers will be pulled away for “just a few days” to deal with some horrible crash or exploit in the game you just shipped, which might actually stall the whole team because everyone’s work is interconnected. It assumes that the design itself is perfect, that all systems will work as imagined on the dry-erase board, and that everyone’s artistic and technical ideas will fit neatly together in the final product.

Continue reading ⟩⟩ “This Dumb Industry: In Defense of Crunch”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.