A paper on “crunch,” a type of burnout endemic among game devs (see esp. the argument that NDAs serve as a source of the problem); an argument that reader mode is an unappreciated browser feature and some useful resources.
Crunch: Working unpaid overtime to reach looming deadlines
so frequent, that it has even spawned a shorthand term for it
Among many developers within the industry, crunch is considered a necessary part of development, or at least unavoidable.
I will explore the causes of crunch, splitting them between two classifications:
sources that are the circumstances and practices that motivate crunch, and
methods that are the cultural contexts and perspectives that instruct developers to crunch in response to the sources.
I then compile solutions to address the causes outlined,
separating them into three levels: team, project, and individual,
which target their respective scale within a games studio.
Causes can be appraised for whether they are a source or a method, which will inform developers how they should be approached.
Sources are tangible challenges that must be addressed directly through management strategies and action.
The difficulty sources present is that they cannot be simply stopped forever, but will require constant diligence as they are faced in every project.
Methods are perspectives and thoughts that require a long period of time to reverse through constant exposure to contradicting evidence.
The challenge these pose is maintaining habits long enough so that a team’s culture can be effectively reconstructed.
Newly identified causes can then be addressed with solutions at either the team, project, or individual level.
Placing a solution into a level tells the team who is responsible for its implementation, how long the practice will last, and what the fallback solution will be if a level fails.
Causes of Crunch
The causes of crunch are deeply interconnected, so to better understand their relationship they will be split between
sources: the circumstances and practices that motivate crunch, and
methods: the cultural environment and perspectives that instruct developers to crunch in response to the sources.
Sources of Crunch
The most common source of crunch, according to developers, is deadlines
However, lacking ample time to complete necessary tasks is only one half of the original incentive to crunch,
with the other being actually having enough tasks to warrant it
Each of these upstream sources can be split into the different stages of development (pre-production, production, and post-production) they reside in
pre-production: to establish the scope (the features and assets implemented in the game) and timeline of development,
where failure to do so accurately sends ripples throughout the entire project.
production: the effects of inaccurate estimations, combined with inefficient and ineffective management, result in the bulk of the sources of crunch.
One of the most common is “feature-creep” where features are added mid-production to a degree where the originally planned scope is no longer accurate.
The severe, and unresolved technical debt typically incurred by final crunch then pushes developers to crunch further
post-production: there is still a final source of crunch that can appear: a lack of publicized records.
A significant part of why estimation may be inaccurate during pre-production is the lack of experience to pull from.
Methods to Crunch
employment pressures and the image of the passionate worker, go hand in hand.
The idealized image of a developer without the need for rest serves as a principle goal within the industry,
prompting developers to behave as such in the pursuit of perfection,
typically expressed through an “over-indulgence” in their work, which justifies crunch as an expression of their passion.
the belief development is unmanageable and a resistance against management frameworks,
serve to prevent developers from searching for alternatives to crunch.
The perspective that games are unmanageable is pinned to them being a creative project,
not simply one of software development, and the lack of control developers have over their own projects, particularly due to publisher influence
as an “anti-corporate ethos”, a nostalgic preference to games’ indie history of garage development,
to effectively dissuade developers from pursuing management frameworks and development practices that can mitigate crunch.
this perception is informed by the circumstances developers find themselves in, particularly the “norms of secrecy” caused by NDAs, clarifying that rhetoric is not the only factor contributing to their construction.
The separation of causes between sources and methods is valuable,
as it communicates that crunch is not the “natural” solution to challenges faced in development.
the cultural context a project and its developers exist in informs which solutions they pursue
the usage of NDAs as a cause of crunch
It is an exception among the causes, since NDAs are largely outside developers’ control.
NDAs are a problem enforced by publishers, and can only be ended by publishers.
Two changes must be made to NDAs within the games industry.
The first is that, at a minimum, automation and specialized tools must be excluded from the NDA’s confidential information.
This includes tools for exporting, testing asset functionality, documentation, and asset development (e.g. Maya and Photoshop plug-ins).
The repeated construction of tools is a considerable waste of resources when a development team could simply collect what they need from git repositories, which were published during past projects.
the second is for the length of obligation to be defined by project life-times.
postmortems of development, management strategies, pipeline descriptions, and architecture for commonly seen features.
Solutions to Crunch
The first level, the team, is meant to target long lasting practices and culture within a development team.
These practices should be employed by either production leads, or held as core pillars of development by the studio.
The intention of these principles is to both reduce sources through organizing development, and combat methods by building an environment with clear expectations and goals.
The second level, the project, accepts that no one process will work across all games’ development,
and so focuses on adjusting to each project in order to minimize crunch caused by the unexpected
The third level, the individual, consists of personal management practices and advice for developers
in order to help them stay out of crunch as much as possible in their day to day work.
[The post is a short note discussing how to enable reader mode in Chome by flipping
k1m [operator of fivefilters.com]:
In our case, we try to match using the XPath selectors that we have for the site.
If we don't have any, or they fail to match anything for the title, author, or body, we then go to Readability and let it do its thing to try and extract whatever we're missing.
[Mentioned in the HN comments as being helpful to make a website friendlier to readability parsers.]
Microformats are a simple way to add more meaning to your HTML.
By adding Microformats to your HTML, your website becomes more understandable to various kinds of computers.
fivefilters/ftr-site-config: Site-specific article extraction rules to aid content extractors, feed readers, and 'read later' applications.
Site-specific article extraction rules to aid content extractors, feed readers, and 'read later' applications.
[The parser library behind the commercial service Full-Text RSS Feeds]
author: //meta[@name="author"]/@content title: //meta[@property="og:title"]/@content date: //meta[@property="article:published_time"]/@content
A standalone version of the readability library used for Firefox Reader View.
This browser is called EinkBro. It's designed to fit Eink devices' needs; no unnecessary UI transitions, clear B&W icons, useful feature for eink reading experience. It's originated from FOSS Browser, which is fully free/libre (as in freedom) Android app.