"There is a dangerous notion of team members being 'heroic' when individuals pile into problems and crunch like crazy to fix them.
#Crunch meaning game industry code#
And, how much more frequent are bugs in code that's written and art that's checked in at 10pm, versus work done in the normal working day? Similarly, eating pizza while 'working late' usually means you're not really working, you're just sat around the office ordering and eating often middling-quality food while not achieving much at all. Come in, work your day, go home, live your life. We flex 30 mins earlier if it helps with school or travel, but that's it. That's why at Wish we operate a standard 9am to 5.30pm working day, with an hour for lunch that we encourage people to take (and to get out of the office, or at least sit in the kitchen, to get away from their screens). "You also need to be honest with your team - it might seem cool having people start at 10am or later, but that leads to leaving at 6.30pm or later - there's still a working day to be done. I find this entirely toxic and incredibly risky" I think that that the decision making related to feature planning grows more confused and less logical as accumulated exhaustion kicks in. Is it really worth staying late to implement a 'cool' feature that 95% of users will barely notice? What are the knock-ons of that feature on other parts of the development team? I would argue it's a waste of time, or even worse, outright risky for the entire project. "Equally, you cannot lean on just one of those solutions - it has to be a mix. The solution is to plan sensibly, to trim specifications, to hire enough people, and to learn that it's okay to say no to external forces now and then. To be fair, if used very sparingly, for a day or two, I think that additional hours can help if something is in crisis, but over the long-term they are never the answer. "The myth arises that working late will fix the problem. It's usually a fatal combination of those factors. These I would summarise as: poor planning by (often inexperienced) managers under-staffing of the team over-specification of the product and refusal or inability of middle management to push back on demands from above or outside. But as I've learned over the years, the issue was down to a combination of commonly occurring issues. Starting out in journalism in the '90s, I was normalised to the idea that 12 to 14-hour days, even working through the night on a heavy deadline, was what it took to get the job done. "I worked some pretty horrendous hours in my 20s when I was establishing my career. So we asked a few of them if they'd be willing to share with the world their advice on preventing crunch from happening.Ĭasper Field, Wish Studios (Small Sized Company Winner)
Within those group of winners, a large proportion of them boasted about "zero-crunch policies" and "avoiding crunch at all costs". Last week we revealed the Best Places To Work in the UK: a timely reminder that not all games developers are suffering. What is bad project management? What is good project management, for that matter? What tips and tricks could be employed to reduce overtime and crunch as much as possible? Simply saying that it's down to 'bad project management' isn't especially helpful to anyone. Crunch is bad for the team and it's bad for the business.Īvoiding these issues, however, is not easy.
When I worked in QA myself, some 11 years ago, the bugs I reported for Ratchet & Clank: Tools of Destruction at 3am one morning needed completely re-writing the next day. There's plenty of evidence that tired, over-worked staff perform well below standards. Yet crunch is not just bad for staff, it can be bad for business. This week has been dominated by a recurring conversation that happens frequently in the video games industry - the matter of crunch.Īlthough 100-hour weeks are certainly not normal in games development, having to put in multiple extra shifts during deadline periods is not uncommon.
0 kommentar(er)
