My column this week will be a bit of a re-run for those of you who have been around long enough to remember the last time I brought up crunch mode in video game development. On one hand, it feels silly to cover the same topic again and again. On the other hand, it’s even more silly that this is still a problem after all these years. The news doesn’t stop covering a natural disaster just because it’s day 3 and everyone knows about it. They cover it until the destruction ends and the mess is cleaned upActually, they probably stop covering it when people stop watching, but you know what I mean..
Some people take the hardline stance that “crunch should never happen”, and I just can’t get behind that idea. It’s built on the premise that since all mistakes are avoidable, you can avoid all mistakes. This is clearly not the case. As an engineer, I’m much more comfortable with designing systems with a bit of fault tolerance than designing systems that are perfect as long as nothing ever goes wrong.
This is a world of finite resources, bedeviled by selfish jackasses, subject to entropy, and filled with unpredictability. Jerks will cause problems, misfortune will strike, people will make mistakes, and equipment will fail. You can insist that all game budgets should be mapped out perfectly and then sufficiently padded, but this ignores the way that creative projects will expand to consume available resources. If feature creep is a problem when schedules are tight, then how much worse will it be when everyone has lots of “extra” time?
Saying teams should never crunch is like saying that airbags are a waste of money because accidents shouldn’t happen in the first place. The pursuit of an unattainable ideal will prevent you from building a robust system.
So how would I handle this?
T w e n t y S i d e d