Simpson's Paradox

A common metaphor we all hear in game development, and software development in general, is fire. After an absence, we ask our team what’s on fire. We talk about projects that are on fire, we refer to fighting fires as we try to solve development problems in the face of release deadlines. I’m personally guilty of this, I triage my tasks into what’s most on fire to solve first, and I use those very words when I do so.

Michael Saladino believes this disaster metaphor is a symptom of a lack of understanding the problems in game development. Smart studios should work to give up the disaster metaphors, and start viewing problems like treating cancer. In this model, problems in development should be addressed as symptoms of a larger problem.

The fire is not, say, a looming and impossible milestone, but a symptom of a systems failure. That milestone that’s giving the team such a problem didn’t occur in a vacuum, so is the cause a poor management call? A team too small for the workload? Ineffective software? Wildly differing expectations from different departments?

Smaller problems will point to the root cause, but unfortunately, these low-level problems are often ignored. Whether it’s a too-small team, poor management, flawed software, or dozens of other systemic challenges, this root cause will continue to result in low productivity.

Good crunch is when the team orders pizza into the office, and stay late completing tasks and hitting a deadline. In good crunch, meeting a deadline is a motivator. The dev team all want to hit milestones and hit ship dates, and they’re ready and willing to stay late to make that happen.

Bad crunch is when the entire team works evenings and Saturdays, spends Sundays trying  to sleep off some of their exhaustion, and drag themselves in on Monday to do it all over again. Bad crunch is sustained. Employees burn out, leaving the games industry or at least the company.  (For anyone who may be unfamiliar with it, I’d like to point you to Erin Hoffman’s 2004 “EA Spouse” essay on the state of crunch and the development lifestyle. And in the tech world, Facebook’s Sheryl Sandburg just made headlines for announcing that she leaves work early — at 5:30 — every day to be with her family.)  Often a crunch schedule’s long hours are instituted by the company, when management calls in the employees’ promised dedication to work, in order to ship a product on time.
Saladino points out that when faced with difficult goals, many employees start their own crunch time. When an employee feels that his deadlines are impossible, that he’s hitting a low percentage of his goals, that he’s being pulled in too many directions, or whatever the flag is that his work is slipping away, employees will stay later and create their own crunch schedule.

This is caused by people who are dedicated to the job and the product, facing impossible deadlines. Saladino doesn’t actually spell this out, but I believe that this self-imposed crunch comes out of employees who are committed to the game and to the games industry. Otherwise, why not be out the door at 5:01 PM?  That same motivation and the same work ethic that causes good crunch and higher productivity also creates the productivity drain of long hours.

Saladino refers to his thesis that bad crunch is a symptom of a systemic illness, and to eliminate this symptom, a good studio needs to diagnose and cure the root cause. To this end, he suggests many ways to clear up communication and process, and to set and achieve reasonable milestones.

Good advice for an industry known for long hours and early burnout, but it will be interesting to see how many studios can take the time from firefighting to remodel the development process.