If You Agree to Crunch, You're Part of the Problem

Recently, Ben Kuchera called to light a eulogy for LucasArts, drawing particular attention to the sacrifices made by employees in enduring crunch. In his words, crunch is a "monstrosity" not to be romanticized, and that's actually a pretty good way to put it. For not only is it a wholly destructive force unleashed on those who work in the industry, it also never seems to die, no matter how many times we try to kill it.

And as developers, it's our fault.

What is crunch?

Before I get into the hows and whys, though, let's quickly establish some definitions.

Overtime, which is a component of crunch, is defined as working more than 8 hours in a day, and more than 40 hours in a week. Some places vary in those numbers (e.g. Alberta, Canada uses 44 hours for their week), but it's roughly in that ballpark for most of the world.

Crunch is the "sustained" application of overtime. Definitions of what "sustained" means here vary, but I think all will agree "months" qualifies without hesitation. "Weeks" has a pretty good shot of qualifying as well. "Days" is probably arguable, and starts to depend on how often within a month it happens.

Crunch is, basically, leaning on overtime too heavily to solve problems. And as it turns out, there are some more concrete definitions of how much overtime is "too much."

Why do we crunch?

What is good about crunch? Why do we do it?

Ostensibly, crunch is meant to increase productivity of a given set of developers within a given time frame. Evan Robinson actually addresses this question in his Why Crunch Mode Doesn't Work: Six Lessons:

Management wants to achieve maximal output from employees — they want to produce a (good) product as cheaply as possible. They also want to avoid hiring extra resources that increase the cost of the finished goods unless absolutely necessary. On the surface of it, Crunch Mode looks like the most obvious and logical way to reconcile these two desires.

He also points out that this is often related to a looming project deadline. He then expresses that assumption as a simple, linear function:

O = R * t

Where O is the team's total output, R is the team's rate of output per hour, and t is the number of hours worked.

However, as Evan's extensive research illustrates, R is not constant over time. R actually varies over the course of a normal work day, peaking in the first 4-6 hours. In fact, R approaches and even drops below zero after enough hours, resulting in negative output for workers.

Effectively, an employee starts damaging the product they work on (bugs, quality issues) if left to work for too long continuously. (For reference, Evan cites 21 as the number of continuous hours of work one needs to reach a mental state equivalent to being legally drunk.)  Conversely, working 8-hour days was shown to produce a 16-20% productivity boost over working 9-hour days.

What's more, prolonged periods of long work days start to produce a cumulative fatigue, reducing the average daily rate R by more each subsequent day. In The Revay Report, experimenters found that 60-hour weeks boost productivity for a few days, but productivity noticeably dropped after a week, cancelling out the boost at 2 months, and continuing to worsen over time after that. (see figs. 2, 3a, 3b, page 2)

Evan goes on to point out that every single other industry has spent the past 100 years optimizing this formula, and has arrived at the 8-hour day, 40-hour week. In Evan's words:

Any way you look at it, Crunch Mode used as a long-term strategy is economically indefensible. Longer hours do not increase output except in the short term. Crunch does not make the product ship sooner — it makes the product ready later . Crunch does not make the product better — it makes the product worse.

I don't think I could put it any clearer than that, except to point out that this is only how crunch negatively impacts the product. For the other drawbacks, I certainly can't put it any better than those who already have. In short, crunch ruins lives, products, and sometimes companies, with no up-side.

How is this our fault?

So how is crunch our fault? I mean, developers are the victims, aren't they?

It's true that developers bear the brunt of the pain in crunch. And it might be comforting to imagine that someone "up the pay scale" is responsible for botching things enough to warrant crunch. It's that last phrase, though, that's the problem: "enough to warrant crunch."

How can a project ever warrant crunch? We've already shown that crunch has a purely negative impact except in the shortest of intervals. So how can we agree to do it? Whether for selfish reasons or love for our product, how can we say it's "ok" to begin working in such a way that damages the product, ourselves, and our coworkers?

Nothing warrants crunch. As we've just seen, industry has been wrestling with the pros and cons of crunch for a century now, and crunch has been shown to be ineffective. Crunch is not a rational option. And our guilt is enabling crunch to happen in the first place.

If you agree to crunch, you are incrementally making the whole industry worse for everyone, yourself included.

Take a moment to let that sink in. Everyone is worse off for your agreeing to crunch. You have to work more, and deal with mounting stress and diminishing rest. Your coworkers have to agree or appear unreasonable in the face of your compliance. The lives of those around you and your coworkers are affected. And your company is forced to absorb the drop in product quality, along with a workforce that's losing competence, morale, and loyalty by the day.

Crunch isn't helping anyone. And by agreeing to it, you're making it easier for crunch to exist.

What if your manager asks you to crunch?

In short, tell them "no." Be polite about it, of course, but don't let politeness give way to bad business.

Look at it this way. By asking you to crunch, your manager has simultaneously just done two things:

1. Indicated that they have failed to manage the project appropriately thus far.
2. Indicated that they have no clue how to continue going forward.

Now, if you like this manager, it might be a good time to pull them aside and direct them to this post, or Evan's piece, or any of the research sources Evan used. If they didn't know, fair enough. Now they do.

If they still insist on crunch after learning about its negative effects, you might want to say "I'll think about it" and speak to their manager. Again, arming yourself with polite concern, and some established research on the topic, hopefully you can impress your point on someone with more experience and reverence for historical data.

If you find yourself talking to more than 2-3 managers in this way without progress (or run out of managers), you might want to consider another option: finding a new employer. Because any company willing to impose crunch on their employees at that many levels of management has a deep-seated philosophical problem, and it may take more than common sense to fix it.

What if your manager doesn't ask you directly?

What if you're in a place where crunch is the elephant in the room? I.e. nobody explicitly asks you to crunch, but it's implied that overtime is expected? Perhaps that's just "the way it's always been," and sticking to normal working hours seems like an invitation to be fired.

Again, this is a topic to be broached with managers. Give them the benefit of the doubt. Bring it up, and see where things go. As above, if you can't make any progress after 2-3 rungs on the company ladder, that may be a sign you're in a place that's unhealthy.

What if they fire me?

What if they do?

Ask yourself that, seriously. If the company you work for sees your concern about unhealthy work-life balance as cause for termination, I think you can safely write them off as an employer you want a relationship with any longer.

You may have heard (or even been told at some creepier companies) that there are 100 others waiting to take your job if you leave, so it's no skin off the company's teeth if you go. That's not true, though.

Good companies recognize the true cost of finding and training good workers. It takes time and resources to find a good worker, and more to train them in your company's workflow. If your company doesn't recognize this, it's probably not a good company. They'd be doing you a favor by firing you.

What if I'm compensated for crunch?

In light of the aforementioned effects of crunch, this should be irrelevant. The focus should be on removing crunch entirely, not putting a band-aid on it.

If employees were compensated for crunch, we might see a change in crunch habits in the industry, but that's just conjecture. As it is, employees are rarely compensated fairly for their crunch, either in dollars or days off.

California may be the one place where this is addressed by law, promising anyone under $83k annual salary ($39.90/hr) time-and-a-half pay for any and all overtime (Labor Code Section 515.5(a)(3)). They also define several exceptions and exemptions, which mandate overtime for entry-level or in-training software fields, film and television artists, and writers. How this impacts software development in California remains to be seen, though.

However, whether you're compensated for extra work or not doesn't address the bigger issue of whether your management knows what they're doing or not.

The bottom line

The point to remember here is that a century of industrial research and work hours testing has resulted in the nominal working hours of 8 per day, and 40-44 per week. This combination produces the highest sustainable productivity possible.

In short bursts, overtime can produce a slight boost in productivity. But the boost wanes after only a few days, and actually cumulatively grows worse each day after that.

If your employer is suggesting (or fostering) an environment where overtime is sustained longer than a few days, start considering whether they're causing more harm than good. See if you can open a dialogue with managers or HR to address the problem in other ways. And be prepared to say "no."

If you like your employer, reward them accordingly. Give them diligence, timeliness, hard work, honesty, creativity, accountability, loyalty, and all the other things you're paid for. In exchange, expect them to provide a healthy working environment, tools and support, intelligent planning, and monetary compensation for your efforts.