Death March Crunches: 10 Causes and Solutions

There are all sorts of reasons for extended, enforced crunch (or death marches) in game development (I'll just call it crunch here).    They are all avoidable.  

Below is a list of 10 of them from my experience and a brief description of proven solutions (full solutions would require a book-length article).

1. Fixed scope, schedule and cost

It’s OK to have a fixed schedule for games, but when you fix the scope as well, you’re asking for problems.  Forget about being able to plan enough to eliminate that uncertainty by remembering Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law." 

Solution: Scope is the best and most flexible tool.  Use a prioritized scope, develop from that and derive your schedule.

Development Debt

We often build up a "debt" of work during development that is unpredictable, grows like financial debt and has to be paid back at the end through extended crunch.  There are different flavors of debt:

2. Technical debt in the form of bugs and late optimization.

Solution: address debt as soon as possible through an iterative approach that frequently delivers potentially shippable builds.  There are a number such approaches; test-driven development is a popular one.

3. Content debt in the form of a minimum required set of polished assets that have to be produced after the mechanics are created,  to tell a story or provide a minimum gameplay experience.

Solution: Build increasing fidelity prototypes and tests of assets during preproduction to measure and extrapolate the cost and schedule for full production.

4. Design debt in the form of waiting until all the technology and assets are in place before discovering whether the experience is fun enough for a full good game.

Solution:  Use iterative development is used to explore gameplay and to “find the fun” early.

5. Feature creep

We all know that the scope we ship is never what we initially planned and that feature creep is inevitable, but if there is a lot of debt being carried, it's hard to measure true progress.  This makes it hard to gauge the impact of additional features requested.  We end up backloading the game with even more "90% complete" features and therefore even more debt.

Solution: Address debt first, so that the true cost of features can be measured.  Then prioritize the feature list so that you can have conversations about where additional features can be added and what features are demoted as a result.  As long as it's understood that the feature list is not a promised set of features, but a prioritized one, where the lowest priority features can be dropped, feature creep can be managed.

6. Lack of courage

Middle management has made promises to stakeholders that can’t be kept and enforces extended crunch on development in an attempt to hide it.

Solution: Upper management needs to create a culture of transparency and not punishing those who deliver the bad news.

7. Risk adversity

Avoiding the areas of greatest uncertainty, such as unproven mechanics or new hardware in the hopes that it won't manifest.  When the risk triggers, it’s too late to do anything smart about it.

Solution: Embrace risk and prioritize work to mitigate it as early as possible.

8. Team ability

The inability of the team to make the game envisioned, due to missing skill-sets or a lack of experience.

Solution: For the short term, a risk-prioritized approach, will inform you early that the team existing cannot make the game hoped for (see courage).  For the long term grow your people through mentoring and training.

9. Ignorance of the limited benefit of crunch

For a many decades, businesses have known that crunch isn't effective past a few weeks.  The data is clear.  Sure, some extra time now and again isn't bad.  At times I've had to drag myself away from the keyboard after marathon sessions, but that doesn't mean we can or should do it for months.

Solution: As a manager who was guilty of this, I had to measure what was making it into the game, rather than just measuring how many hours people were at work.  That demonstrated the loss of value we faced with extended crunch.  That was the last time I enforced it.

10. Lack of empathy/respect

The attitude that game developers are fungible, that crunch is part of the territory if you want to make games and that they are to blame for a bad process.

Solution: Quit and work someplace that respects you.

---

Conclusion

We all have to put in extra hours from time-to-time.  In fact, some of my best memories were working late with my team to get the E3 build out in time or to polish some mechanic we were excited about.  Sometimes, we'd have to limit it ourselves to avoid burnout.  

This is different from the institutionalized death marches and "scheduled crunch" commonly practiced.  There is no good reason for it.

One last question

What is missing from the list?  What are solutions have you seen?