That Awful “C” Word: A Student Perspective

Reposted from AltDevBlogADay

I’m always quite concerned about speaking my mind on industry topics. I am, after all, just a student – albeit a mature student with some (old & outdated) industry experience. I know that a lot of my speculative arguments, theories and opinion pieces could be shot down with “you don’t know what its like”.

There’s one topic, however, that I have very strong feelings on, and that I feel, as a student, I can offer some perspective on: CRUNCH.

Being a student, crunch is something I come up against all the time. When exam/deadline time rolls around, our library goes into 24-hour opening times, the union starts dolling out caffeine tablets like candy, and the counselling department pretty much just opens its doors to accept the cracked and broken souls that don’t make it through. Throughout all of this, though, the message is clear: it shouldn’t be this way. Do you work early and pay attention to your time and you’ll be fine. To “crunch” in University, however common it might be, is seen as something you do because you’re too young/naive/unprofessional to handle your deadlines responsibly.

What worries me the most about crunch in the games industry is the view of it as acceptable practice. I worry this can lead to an exponential explosion of crunch-time, leading to a dreaded state of near-perma-crunch. By accepting that crunch happens because of deadlines, producers then begin to schedule crunch time into the plan. Which means that when unseen problems come along, the stress rises, because you know crunch is coming anyway, so you have to crunch more for the new problems. Thus crunch happens earlier, or more intensely. This becomes a habit, gets accepted, and finds its way into the schedule for the next project, and so on …

In the course of the last year, I’ve developed 3 (admittedly tiny, barely-finished & prototypical) games at Uni, and – believe me – I can appreciate how difficult it can be to properly predict and scope a development project. Games development is, by its very nature, unpredictable – you can’t really “sketch” the play of a game the way you could a painting, or outline it the way you could a lengthy essay or dissertation (ways in which you might attempt this are a topic worthy of its own post).

At the end of the day, however, we are being taught to work as professionals. This is something that I both love and loathe about our course (blatant shilling alert!): unlike some more liberal, artistic courses, Abertay University’s Professional Masters in Games Development is all about the business of making games as professionals. We might not be encouraged to be as innovative and creative as possible, but we have producers, we have schedules, and – yes – we have deadlines, and by and large we hit them, because the job of producers is to make sure that the project hits those deadlines. They cut content when they have to, they reign in designers when they have to, and they generally work towards that singular goal – crunch is essentially their failure. If they ask programmers to stay late, they do it as a favour to cover their butts.

Where developers are willing, or in some cases even wanting to put in extra hours, I feel like this is something that needs to be more carefully considered than the “hey, if they’re willing to do it” attitude. A good producer should see the developer as a whole, and the company culture is a big part of that. If some of the team are willing and dedicated to working extra hours, then it creates a culture of overtime that can suck in those who don’t want – or worse, can’t – put in that extra time. Not to mention that there are those developers who are so dedicated to a project that they’ll literally work themselves into ill health for their passion. A good producer should get the best from their team – and often times that might mean telling someone they need to stop working and go unwind. Simply buying dinner or drinks for hard-working teams can, in some cases, be seen as treating the symptom (stress and fatigue) rather than the cause (overwork) of a problem.

On top of this, producers (and any team member associated with people and resource management – lead artists, programmers and designers) must consider the value of each step in the development process. A poor pipeline leads to downtime, confusion and work that does nothing but gets lost in the ether. This not only produces delays in development, but also increases frustration and lowers morale.

Thus, I feel that the root cause of habitual crunch is a lack of professionalism – not professionalism of low level developers (although I do feel that not speaking out against habitual crunch as a practice is a little amateurish) but the professionalism of higher-ups, managers and producers.

Perhaps I’m way off base here, and the problem lies somewhere with publishers not offering realistic deadlines to developers. Perhaps production in the industry works fairly well – but the fact remains that the image projected by the industry still tends to be that working harder = getting more done. I would argue that the more professional approach would be not to work harder, but to work smarter and more efficiently by understanding not only the process of development but the needs of both the individual developers and the development group as a whole, and maintaining a healthy working environment and culture for all.