Why Crunch Mode Doesn't Work

so sue mee writes "There's a bottom-line reason most industries gave up crunch mode over 75 years ago: It's the single most expensive way there is to get the work done. When used long-term, Crunch Mode slows development and creates more bugs when compared with 40-hour weeks. Evan Robinson has an article at the International Game Developer's Association site talking about the harsh realities of crunch time, and why the gaming industry should stop using it." From the article: "It is intuitively obvious that a worker who produces one widget per hour during an eight-hour day can produce somewhere between eight and 16 widgets during a 16-hour day. As we've seen, that's the essential logic behind Crunch Mode's otherwise inexplicable popularity. But worker productivity is largely dependent upon recent history."

Comments

75 Years? WTF?

[SpaceLifeForm]

Computers have not been around that long, and crunch mode in IT is still in vogue!

Obvious

[mind21_98]

In my opinion, if you need crunch time to finish a software product, you've done something wrong. It's much better to encourage a culture of efficiency and program stability than to make up for it by forcing it down people's throats close to the ship date. *shrug*

Re:Obvious

[Anonymous Brave Guy]

To be more precise, if the development staff need crunch time to finish a software product, then chances are that the management did something wrong.

Re:Obvious

[Anonymous Coward]

They'll plan better next but for now, we need crunch time.

"just this once is the mantra of the incompentent"

Re:Obvious

[Cornflake917]

What I want to know is if there are any big game companies that have actually done away with crunch time. I mean it IS horribly obvious that crunch time causes problems and limits productivity. Furthermore, I think it scares many skilled and talented programmers away from the game industry. With so many reasons to trash crunch time, why haven't we seen this happen??

Re:Obvious

[brkello]

I think that is a bit naieve. In almost any project there is crunch time when it comes close to a ship date. With software, there are generally agressive ship dates that are set. As annoying as this is, a lot of times customers change their requirements on you and you have to scrable. So even good planning isn't going to save you there. Crunch time is fine as long as it is a short period. You can get a lot of quality, focused word done. Extended perirods of crunch time leads to burn out and poor product quality. You need to find a balance.

Re:Obvious

[badasscat]

In my opinion, if you need crunch time to finish a software product, you've done something wrong.

You're not quite seeing it the way the publishers see it - it's not crunch time as in "holy crap, the deadline's coming up, we'd better work overtime!" It's more like a standard schedule. It's actually built in to the project timelines. It's not a surprise. You know that four or more times a year you will be working 80 hours a week, and management knows they can create milestones based on that schedule.

The way this came about most likely was accidental... you often hear stories from days of yore about things like the original Pac-Man for the Atari 2600 being developed in 6 weeks because Atari realized they had the license but had no product for Christmas of that year. The problem is, as even this article points out, crunch time does work in short bursts. The publishers learned this fact, and came to rely on it through a series of these happy accidents, where workers who were otherwise excited about what they were doing were asked to put in extra time on projects to make up for mistakes... and they did it successfully.

Once you start to make it less of an anomaly and more of an everyday thing, though, that's when productivity starts to drop and discontent starts to rise. Management doesn't really see it this way, though; they only do the math and figure that more hours equals more productivity at the same salary level. Obviously, this is poor management, because not only does it not hold true after a certain period of time, but it ignores other inevitable problems, like the incredibly high turnover rate that results... which costs a huge amount of money. (Recruiting a new worker for a full-time, non-management, white-collar position costs approximately $80,000, last I read, including lost productivity during the replacement period, training, new benefits, the actual search and interview process, and other miscellaneous HR costs.)

The game industry is young, as are most of the managers and even CEO's involved. (When I worked for a game publisher, my boss - the CEO of the company - was younger than I was, in his late 20's.) They simply do not have any real management skills or training. They are wasting huge amounts of money without even realizing it, in fact believing they are doing the opposite. They think they have stumbled upon some magic formula for business that nobody else has ever thought of - simply drive your workers as if they're slaves! They don't know that everybody else has already tried this and figured out it doesn't work.

Eventually, as the industry matures, this will likely change... though by how much is anyone's guess, as it's a culture at this point. But already you're seeing quite a bit of consolidation as poorly-managed companies get merged into larger, better-managed companies - or simply go out of business. But even heavyweights like EA obviously have their problems, and once the growth spurt we've seen over the past decade or so subsides, they will have to deal with their management issues too. (If they're smart, they'll do it now, before it's too late.)

Re:Obvious

[Anonymous Coward]

What I want to know is if there are any big game companies that have actually done away with crunch time.

-Insert "Duke Nukem Forever" joke here-

Re:Obvious

[Anonymous Coward]

Yeah, like listen to the development staff when they gave time estimates at the start of the project.

I've seen it done both ways -- managers make the schedule without consulting developers, and managers make the schedule with the development team, and it doesn't seem to affect the crunch rate either way.

The only real way to avoid crunch is to be working on such a popular game, that's already made so much money, and continues to make so much money, that you can "ship it when you're ready." And you still crunch at the end.

Re:Obvious

[cratermoon]

Quite true. And one of the mistakes management makes is hiring people who can't or won't estimate correctly. On prefectly reasonably well-run projects I've been on, things don't get done because some hot-shot lone coder tells management he (and it's always been guys in my experience) can do in half a day what will actually take 3 days from start to completion of integration and testing. Sometimes they just plain don't actually know how long things take. Often, the only portion of the task they think of as taking time is typing time. These wishful thinkers typically type in the change they think is right and check it in and call it done.

If this sounds more like the coder's fault, let me assure you it's not. Miss an estimate once or twice, OK. Nobody is perfect, you learn and move on. Consistently fail to estimate correctly and management needs to take notice. Either pull that person out of the critical path (so missed deadlines don't hurt so bad) or have someone else who has shown better estimating ability size the task and use that number.

If, after 12-18 months of work, management is still letting someone who makes committments he can't keep blow the project's schedule, that's pretty much professional malpractice in any real profession.

Re:Obvious

[Anonymous Coward]

This post nails it.

As a producer, I do get aggrivated when people are like "producers need to talk to developers when they schedule." Oh, really, no shit, thanks! That never occurred to me!

But the reality is that estimates on complicated tasks (basically talking about implementing new technology here) are almost *always* wrong, regardless of hot-shot quality. Sometimes you can add multiplier to a particular hot-shots estimates (like, any estimate Toby gives you, simply multiply by 3 in the schedule), but even when you add the multiplier on a hot-shot's estimate, it's frequently off.

A more interesting question is to figure out why the estimates are wrong. Usually, in games, it's because there's unanticipated stuff that comes, not just stuff that people should have thought of, but stuff people, even hot-shots, never would have reasonably thought could happen when you're implementing new technology. Stuff that only a hot-shot can solve.

So the ideal solution may not be to marginalize a poorly estimating hot-shot, or have someone else make an equally uninformed estimate, but to simply schedule unestimatable tasks, or tasks on which you think may have demons lurking there, in parallel with other tasks so that you can keep as much of the team on schedule as possible, knowing that the hot-shots are invariably going to be late no matter how much buffer you try to build in.

Re:Obvious

[Jacius]

As annoying as this is, a lot of times customers change their requirements on you and you have to scrable. So even good planning isn't going to save you there.

It might not save you, but it can definitely help you. Though it may sound counter-intuitive, you can plan for changing requirements, and so alleviate some of the problems. You can keep the design flexible, for one thing (as much as possible, anyway). And if you have good "intuition", you can guess what the customer actually wants (instead of what they say they want), so that when they "change" the requirement (when they figure out that they didn't actually want what they said they wanted), you can be one step ahead. (Paul Graham writes about this sort of thing in his essays sometimes, and he's pretty darn smart.)

I don't think "crunch time"that is, the idea of a period of rapid development where you're doing focused work to get a project doneis bad in itself. It's quite exhilirating when it's your own motivation and enthusiasm for the project that cause the rapid development. It's hell when its forced upon you by the incompetence of someone else, and it wears you out.

I hope that some game companies start using a better model. Then maybe the games will be more fun (because the developers are having fun making it), and they will sell well, and other game companies will ask, "What's your secret?"

And they'll reply with something witty.

Re:Obvious

[cratermoon]

Right. I left out an important point. Estimating is hard. Estimating something you haven't done before is nearly impossible. Estimating something neither you nor anyone else has done is completely impossible.

When management asks for that kind of an estimate, the only reasonable, professional, response is, "I don't know, how long can you give me to research the problem to determine the scope?". Management needs to accept that, and be prepared to respond if the estimate comes back "too long".

In games development, (and plenty of other fields) management doesn't accept that answer. The deadline is set at next Thanksgiving. It's impossible for them grasp the concept that some things can't be estimated.

Management's "solution"-- just push as hard as possible to get what they want, and punish the failures. Reality intrudes regardless, games get delayed or features dropped. Sane people would plan and prioritize features. If task X can't get done in time T, either that feature gets dropped or another, lower priority, feature is dropped to give time to finish task X. There is no "work twice as many hours so you can get both done".

Similarly for unanticipated stuff that comes. Change happens. A perfectly reasonable estimate that can be agreed on by multiple programmers can turn out to be wrong when something else comes up. It's no use railing against fickle customers or glitchy hardware and libraries. But that's another essay.

Re:Obvious

[cratermoon]

If the only time estimation is done is at the beginning of a project, that's a problem, too. Experience and research shows the estimate will be off by at least 2x. That is, a project estimated at 1 year could take 2 years, or could go 6 months.

What kind of insane person looks at a 1-year project after 3 months, sees it's failed to achieve what it had planned for those 3 months, and then just expects to make up the loss without pain? I don't know if that is more, or less, insane than doing a schedule once and then never looking at it again for a year.

Again, when developers make estimates and fail to meet them, management must adjust, and not by having everyone work double overtime.

Re:Obvious

[Anonymous Coward]

they will have to deal with their management issues too.

they will also need to deal with whatever companies they have bought up. As some will probably have issues as well.

Re:Obvious

[OverflowingBitBucket]

What I want to know is if there are any big game companies that have actually done away with crunch time. .... With so many reasons to trash crunch time, why haven't we seen this happen??

Huge and steady supply of warm bodies and marketing-driven deadlines being prioritised over software stability. It is cheaper to work star-eyed programmers into the ground and discard them at the end when the overall quality isn't a priority. It's disgusting.

Re:Obvious

[Jonboy X]

Our dev lead specs out to our manager how long a task should take, and he consistently underestimates, basing everything on his 11-hour-a-day work schedule. The rest of our team usually just half-asses it. I tend to just tell my boss right up front that it's going to take 10-20% longer, at which point the usual response is, "Work late, slacker". Our lead was off for a month, during which time I put in my own estimate for a new project. The manager bitched about the time, but thankfully my coworkers backed me up on the estimate. I was about 3 days from finishing on schedule when the dev lead came back (from India, if you must know), and decided to redesign my project. Now my ass is in the fire for his whimsy, and my manager's general assholeishness.
</bitchfest>

It's a whole different ballgame when your accurate estimates and detailed specs are "re-tooled" right out from under you. After a year and a half of this crap, the tech economy's finally good enough that I'm interviewing Friday with a competitor down the street. Wish me luck!

Re:Obvious

[Anonymous Coward]

Meh. It's capitalism. Why do you hate America?

Re:Obvious

[Anonymous Coward]

Actually I'd say the biggest mistake is having the manager set a line in the sand and not allow the loss of features that cannot make that schedule.

Or my favorite.. "You have 14 days to do it, please write me a costing document that gets everything into those 14 days".

Re:Obvious

[bitkari]

The trick seems to be that with new, and mission-critical tasks, set aside some research time to either come up with a prototype or at least a solid estimate of how long it will take to develop.

R&D time is too often seen as surplus to requirements in game development, but the payoff can be huge if it is used correctly.

Re:Obvious

[ChaosDiscord]

And one of the mistakes management makes is hiring people who can't or won't estimate correctly.

It often cuts the other way: management rejects the realistic estimates as "padded", or imply that the person is being lazy. They demand that the programmer revise the estimate downward. When the overly aggressive estimate is missed they don't stop and realize, "What, he said it would take 10 days, I demanded he reduce it to 5 days, and it took 8 days. Maybe I should trust his estimates." Instead the manager get angry that the programmer missed the deadline the programmer "agreed" to. Depressingly common.

Re:Obvious

[interociter]

the original Pac-Man for the Atari 2600 being developed in 6 weeks because Atari realized they had the license but had no product for Christmas of that year

It's worth noting that the original Pac-Man for the Atari 2600 was the single biggest disappointment ever released for the 2600. I had always assumed that Atari figured that since they'd paid for the rights to the game, they would be the only source for the game, and no one would care if it was any good. Sure, it was a huge seller, but there wasn't a gamer out there who wasn't disappointed when they fired it up on Christmas morning. Hearing that Atari hacked it together in 6 weeks explains a lot. It also explains why there were so many Pac-man clones that were so good in the following months.

Re:Obvious

[cratermoon]

Sure, but demanding that estimates be fudged to fit a pre-determined schedule is clearly management incompetence. The argument I'm making -- based on real experience -- is that when a developer consistently makes optimistic and unrealistic estimates it's still management's fault. One, for believing the estimates and continuing to believe them when demonstratably wrong, two, for hiring and keeping an incompetent.

SSDD

[BrookHarty]

My boss tried that on me again last week, just put in a couple more hours, take on another task, work smarter not harder...

WTF are these people thinking? I'm working a few more hours on the last damn project you gave me, i'm already working smarter since you downsized our company every year for the last 6 years. Take on more work?!

Then he has the nerve to say, if your working more than 50 hours, we can get you time off. Ahem, 60 is the norm there bucko. Tells us he wants us there 8-5 while we are also working maintenance and weekends. Ya, thats gonna happen. Last I checked with HR im salary, you cant make me clock in and out.

Crunch time seems to be the norm. Either your working mega hours, or you are in a quiet time before something breaks. Like Sys-admins are like fire fighters, you automate as much as you can, and when something does break, you work your ass off.

Trying to work as a corporate whore, I mean sys-admin and try to balance a personal life isnt working out so well. Having to deal with PHB's who think computers are magic fairy dust and can make anything happen is slowing killing my soul.. Then come home to a wife who says I'm not spending enough time with the kids, ARGH!!!

So tempted to switch my job for a differnet crunch time. Flipping burgers during rush hour.

American Beauty is a great movie, to say fuck it and go be happy again.

I'd join a union, but all these ass-hats want work and burn out, and of course they do burn out. Happy hour can only keep you going for so long....

Re:SSDD

[Elwood P Dowd]

Look for other work with better hours.

Don't stay there poisoning yourself.

When you find work with better hours, tell your boss you want better hours or you're taking someone else's job offer. If you can't do that, ask your boss to consider reducing your hours in exchange for a pay cut.

My stepmom did that, and it worked to everyone's benefit. She asked for a 10% raise and a 20% reduction in her salary in exchange for a four day work week. Would your boss like to reduce the amount he spends on salary?

Re:SSDD

[BrookHarty]

One of the reasons my boss has been hiring people with no experience, HR wont let him pay anyone a good salary anymore. HR says the market is 1/2 of what we are all making. Say 70K all new guys coming in at 35K, see the problem...

So, the entire team has to suck up the work because they wont pay for a good sys-admin with experience and try to train new kids out of school who burn out, or get trained up and leave for more pay.

We dont work a production line, so there isnt no reduction in work, even a day off you still have the same amount of work waiting when you get back into the office. Task based, self managed type of sys-admin duties doesnt really fit in that role.

You like the freedom, but you hate the workload. Not many jobs I could readslashdot. Most of the company doesnt even get Internet access, sitting at windows terminal services in a locked down enviroment. Operations gets laptops and sun workstations with wireless cards, so we can work anywhere, any time.

Only way out of this 60+ hours crunch time is to goto Engineering, but with all the mergers, they let so many people go. Not great job security there...

But I have great medical, If I had a nervous breakdown or something, I could be on permanent medical leave and still get 60% of my pay.

Re:SSDD

[Elwood P Dowd]

That's really rough, though. There's no need to resign yourself to not seeing more of your wife and kid. If you'd like.

Re:SSDD

[Anonymous Coward]

I hear you.. After 12 years I am jettisoning this lemon of a career (software engineering) like a bad habit. I should have never let it get beyond the hobby stage, which is what originally interested me to begin with. I hope it works out for you, somehow.

Re:SSDD

[supabeast!]

Everything you just ranted about is exactly why I quit doing sysadmin work to go back to art school. After five years in IT I realized that the better I got, the more useful work I would be able to do, and thus I would be expected to either sit on my ass when management had gotten stuff backed up or try not to go insane under pressure during crazy crunch times. It's hard to be happy with all the money a good sysadmin can make if you're too stressed out or busy to enjoy it.

Re:SSDD

[OverflowingBitBucket]

My boss tried that on me again last week, just put in a couple more hours, take on another task, work smarter not harder...

That's when you start looking around to see what else is on offer, just in case.

Suggesting something like "perhaps we need to get an additional person on" is useful. The answer you get to that suggestion speaks volumes.

I mean, I don't come up to you and ask you to spend a couple of hours a week working in my garden for free do I? Why is it okay for someone paying you to work "x" hours to ask for an additional "y" hours as a freebie?

I'm a gamedev

[Anonymous Coward]

And I was at work until 2am last night. I wish I knew a way around crunch time... but with marketing, disk pressings, public betas, christmas, and all that fun stuff, it seems impossible to avoid.

If anyone has any good ideas I'll pass them onto my manager :)

Re:I'm a gamedev

[Lonewolf666]

Ever considered working in another area of software development?
I'm working for a big corp in the medical technology sector (control software for our devices and the like), and we have pretty regular hours. Occasionally, we work on Saturday to keep a deadline, but it is nothing compared to what I read about games development.

Re:I'm a gamedev

[Anonymous Coward]

Indeed. I am in finance. I get to do more interesting math and no one would even *think* of asking anyone to come in more than 40 hours a week. And in the rare case they did, they would pay double overtime and you could just say 'no'. In many ways it is such a nicer culture than some straight development teams I have been on and the best part is I use the same software I develop which makes for very fast development indeed.

I would never take a job with 'manditory overtime' again, and no one should put up with it.

Re:75 Years? WTF?

[Anonymous Coward]

You do realize that there are other industries in the world (and bigger ones) than IT?

Yeah, right

[c0ldfusi0n]

Tell that to EA Spouce, she knows.

Re:Yeah, right

[Mithrandir86]

An important thing to note is the EA doesn't have crunch time. That would imply that the work slows down occasionally.

Working longer just doesn't produce more

[WouldIPutMYRealNameO]

One of the best places I worked was a place where the boss understood that happy workers are productive workers. And workers that are required to work longers hours simply don't get more work done.
This guy kept us happy with relatively cheap methods - decent coffee, free biscuits/cookies and taking us out to lunch/dinner on a regular basis.
Even under stress times he told us to leave for the day. Interestingly this made people want to stay later and work harder.

At other places I have worked there has been an expectation of "we're near deadline, work an extra few hours every night" - for me this doesn't work. I get less done in more time, I end up sitting watching the clock or reading Slashdot, and resenting staying at work.

The solution to getting things done on time is simple
1) Hire smart people who get along with each other
2) Don't push them, let them work hard for 8 hours and then go home
3) Don't choose arbitary dates for shipping
4) Don't let features creap into the spec.

But managers don't seem to understand this.

Re:Working longer just doesn't produce more

[Lonewolf666]

Heh. Our management regularly violates 3) and 4), usually with 3) happening first and 4) going on after that. Without that kind of stupidity, even the occasional work on saturday I mentioned a few posts above would be unnecessary.

Re:Working longer just doesn't produce more

[SkeptAck]

> Don't push them, let them work hard for 8 hours
> and then go home

Honestly, you'd have to let them work 8 hours and then MAKE them go home.

Re:Working longer just doesn't produce more

[blackpaw]

My current work place is like that, its great. I've stayed here the longest I have at any job (3 yrs) and I have no intention of leaving.

And I'm definately motivated to put in the extra hrs when its needed.

Why there's a crunch mode

[Brandybuck]

There's two main reasons why there's a crunch mode. The first is because someone somewhere managed to do it sucessfully. Management isn't stupid enough to cut development time in half, but shaving a day or two off of a three month schedule isn't that big of a deal. So everytime you manage to get your project out in time they shave another couple of days off the next project's schedule. And even if you manage to avoid that, there's always another team somewhere that did manage to succeed with an insane schedule, "so why can't you?"

The second reason is that the schedule you've estimated and the schedule the market demands live in two different universes. Management isn't stupid, they KNOW it's costing them more to make you do crunches. But the market says they need a product out in three months and not six. So you're given an insane schedule.

Re:Why there's a crunch mode

[Taevin]

But the market says they need a product out in three months and not six. So you're given an insane schedule.

If you had RTFA, you would have seen: "In about two months, the cumulative productivity loss has declined to the point where the project would actually be farther ahead if you'd just stuck to 40-hour weeks all along." So actually, not only is it costing them more, they might have the product in two months instead of three if they didn't force crunch mode.

Re:Why there's a crunch mode

[Vicissidude]

Sounds like if they keep crunch mode under 2 months long, then they will get higher productivity.

Re:Why there's a crunch mode

[Anonymous Coward]

Sounds like if they keep crunch mode under 2 months long, then they will get higher productivity.

That's assuming that the employees either have time to recover, or are magically able to instantly return to their base productivity as soon as they start a new project!

Re:Why there's a crunch mode

[vega80]

Nope, there is almost always one reason for crunch mode: Feature creep. On every project I worked on, schedules were made for design doc from the publisher client. These schedules are generally good, even allowing for some slack. Invariably, as the shipping date approaches, some similar game will be released, and the client will say, we need to have that feature or this feature. Generally, this happens around E3. The developer management can say, "no, that's not in our contract" and perhaps not get another contract from the publisher again, or bite the bullet, and the team will have to crunch to put what the client requested into the product, or at least as much as they agree to.

Re:Why there's a crunch mode

[rossifer]

Management isn't stupid enough to cut development time in half, but shaving a day or two off of a three month schedule isn't that big of a deal.

We had been working for 15 months of a 24 month project when the newly hired marketing team finally presented a complete product spec (the previous marketing team had been fired because they couldn't produce a sane product spec and we spent our time running around in circles). We did several estimates on the spec the provided and came up with a range of estimates for a nominal schedule of 22-24 months, +/- 25%. We also figured that we could reuse a good sized hunk of what we'd already written and guessed that that would save us about 6 months, leaving us with 16-18 months of work to complete.

But the original schedule had us finishing in 9 months (remember, we were already 15 months into this "two year" project).

They chose not to alter the schedule. Or substantially alter the spec. i.e., management was stupid enough to "cut the schedule in half". Hilarity ensues.

We ship two months late, and what we ship sucks. Most of the internal data-management frameworks were left half-baked so that developers could spend more time working on screens and reports, which means that even minor changes are painful; performance is pathetic; the UI abuses the user in several ways; and it has errors in data management that can corrupt customer financial data.

But you can't teach management a damned thing about how to write software. They're the ones in charge, so they're the ones who have to tell us how to do our jobs best. Right?

Regards,
Ross

Re:Why there's a crunch mode

[OverflowingBitBucket]

Invariably, as the shipping date approaches, some similar game will be released, and the client will say, we need to have that feature or this feature.

The developer management has a few more options than rolling over and saying "we'll get out the drums and whips". They can factor in additional time for unspecified features at the start in the initial estimate, and make it known that time is available for the publishers to throw in new features, but no more. They can say "We'd love to, but we'll have to take on another developer or two if you want it on time. That'll cost $X, you pay half, we'll pay half". For a show like E3, you can trade off less visible features to implement after the show and pull the visible ones earlier. You can break off a set of tasks and pass them off to an external contractor ("that'll cost $X, we'll pay half each"). Just because the management in a developer won't take a risk at offending the publisher and decide they'd rather abuse their own employees doesn't mean there aren't options.

BUSTED

[Anonymous Coward]

Get back to work - quit reading slashdot!

This is silly

[BlightThePower]

I particularly object to the "what management wants" paragraph. Unfortuantely I detect a coder's tendency to try to over-rationalise the world here. Their analysis does not provide the "essential logic behind Crunch Mode's otherwise inexplicable popularity". I don't believe the cruch is what management wants at all, the problem is simply poor planning. All they want is the software to specification by the deadline. If you can do this without the crunch then obviously this is a Good Thing, but if you can't, thats business.

The cruch is a response to a problem (that may be flawed) but its not the real problem. This is somewhat different from the issues that people like Abbe and Ford were discussing which was the simple problem of extracting sustained and predictable productivity from their workforces.

The difficulty is that the work processes surrounding the writing software appear to be still relatively poorly specified, which is why there are many methodologies -- which attempt to produce sustained and predictable patterns of productivity -- but no silver bullet as yet. A hint to this is that of course Ford was in the vanguard of people who went out of their way, at considerable expense, to enforce a well-specified process behind their output. He had to have that in place before his adjustments to working hours made any sense; the author's analysis of Ford's management style misses this vital aspect out.

Re:This is silly

[Josh Booth]

The specifics of how Ford managed people are not important in this case since all we are debating are ludicrous work hours. As the auther stated, thousands of studies determined that industrial workers actually produce more when they work a 40 hour week (8 hr/day x 5 days) than when they work a 48 hour week (9 hr/day) or more. Why should the gaming industry be any different?

Now, as was repeatedly stated, EA games and other companies are in a /constant/ state of crunch, meaning that every worker is effectively being hired to work a 60+ hr work week. The author stated that such a plan for management is crazy since it is ineffective -- working people for 40 hr/week would be just as effective as long as previous studies in work where progress is more easily measured apply to jobs requiring intense thought. This seems likely, considering that working 80 hr/week means that half of your life is devoted to the company, about a third to sleep, and 1/6 of your life is devoted to yourself. This means that you can spend 3 hours per day for yourself, less travel to and from work and eating dinner, breakfast, and basic hygene. This results in no time even for reading Slashdot. At this point, life is pointless and the worker can't be happy.

Re:This is silly

[BlightThePower]

The specifics of how Ford managed people are not important in this case since all we are debating are ludicrous work hours...Why should the gaming industry be any different?

I've just told you why the gaming industry is different, because software development in general is a poorly specified process unlike industrial processes which are incredibly accurately specified; thus people can't plan accurately just how long a widget is going to take to produce (This is actually stated in the article but they don't seem to draw any connection between special difficulties in the measurement of IT productivity and the special nature of IT working hours; I'm saying they are closely related). As a businessman this causes you to enter into a world of trouble because your core process is unpredictable. This is worse for gaming than most programming because they are a retail business, you don't earn money for games that haven't shipped yet. Put it this way, if you say a project will take 40 hours of productivity to produce and you give your workers a 40 hour week, but half way through you discover your project has changed and you need 50 hours of productivity, then you've missed your deadline.

The problem for software development is that this potential for change is constant, its as true in the first week as it is in the last week. Furthermore, you don't really know what form of work the change will engender, it may be donkeywork, it made need great creativity to come up with new concepts, it may be tracking a bug. A huge amount of money is spent to make sure industrial processes don't change in either their nature or their duration. Ford was the leader in this and when he'd managed to make things so predictable then he could measure productivity accurately and thus could adjust working hours safe in the knowledge of what the outcome would be. He spent 12 years experimenting on this, the gaming industry hasn't been at its current strength for anything like 12 years. Making people work crazy hours even though their productivity will vary widely as a result is a response to this uncertainty and planning difficulty. Your EAian 60 hours gives you considerable slack. Some 60 hour periods will be easier on the workforce than other 60 hour periods though. The only thing that makes the gaming industry different is that they seem to be able to hire people prepared to do this for whatever reason.

Re:This is silly

[CrankyBuffalo]

Actually, it's a coding manager's attempt to rationalize insane behavior :-).

I don't believe that management is happy that crunch mode happens. I do think they want to maximize output, but that's kind of an assumed desire, because what they really want is to produce product that makes a lot of money. Making product that sells well is one branch of that ultimate desire, and reducing the costs of product is another. I don't think management sits around constantly asking "how do we maximize the output of our workers". But maybe they should :-).

I think the major disconnect is the idea that hours in seats is a good proxy measurement for total useful output. This idea is the basis for the decision to use crunch mode (although I'm pretty sure it's rarely expressly stated). It's an idea that's widely discounted by experienced workers and managers (even those who use crunch mode routinely) and the studies agree that it should be discounted. You can say that crunch isn't the problem -- that there are a whole host of reasons why crunch happens -- but the crunch mode technique is, in and of itself, a problem because it actually delivers the opposite of what is wanted when it's used -- more output.

So poor planning is a contributor, but it's not the essential problem. The essential problem is failure to understand that the result of long-term crunch mode is lower total output.

Re:This is silly

[CrankyBuffalo]

Over more than 20 years as an independent developer (mostly in games), technical director at EA, manager in game software development, and manager in non-game software development (core technology), I've managed to plan, estimate, schedule, and deliver software on time without resorting to long-term crunch. Not only did I write the Crunch Mode paper we're discussing, I've been speaking (at GDC and elsewhere) and writing on the general subject of improving development practices for well over 12 years -- since the early 90s, in fact.

In my experience, proper line and project management can correct for failures of initial planning, requirement creep, and even poor scheduling. Of course there are limits: one can't deliver a full-fledged AAA game console product in a couple of weeks just because it's well managed. Of course there are challenges: game development is harder to predict because the elusive "fun" quality is even harder to design than the "useful" or "elegant" qualities that must be in other, non-game, software.

But one common practice that I've encountered which proper line and project management cannot correct for is cultural reliance upon crunch mode. Poor planning can be overcome: willful or ignorant mismanagement on the ground cannot.

Computer and console game software develoment goes back well over 20 years.(I know. I was there.) In the beginning, pretty much everything we did was ad-hoc. Now a lot of it is decently estimated and scheduled, but a lot of it is still not well-managed.

Crunch mode is a symptom of that management failure, not a result of any inherent intractibility of game projects. I've made a career of delivering projects (most of them games) with minimal slip and almost no crunch mode. It can be done.

Crunch works. Death march does not.

[LordZardoz]

In controlled doses, Crunch works. It is perhaps even necessary. Shit happens, and you have to meet a critical deadline, so you work late for a few days in a row.

Death marches dont work. They just result in angry workers and an increased rate of errors.

And yes, I am a game developer, and I know all too well what I am talking about.

END COMMUNICATION

Crunch mode works

[Anonymous Coward]

...for Doritos. And hey, without it what would Cap'n Crunch be like? They'd have to change their name.

I'm just sayin' is all...

Wow - old!!!

[Anonymous Coward]

This article was first available on IGDA's site at least two months ago! What's the deal?

Used Sparingly It's OK

[lbmouse]

Nothing like a good old fashioned death march to get the blood flowing and make you appreciate the 'easy' days.

Still common, but not intentional...

[Taulin]

While 'in the books' the design of a project should be done far before release is near, even if you are doing iterative development. However, many MANY companies still like to design as they go. It is not the developers fault most of the time since many companies create software for clients who know nothing about making software and add change requests, or sneak changes in by claiming the developers mis-interpreted the specs they gave them. Added to this are ambitious managers/developers who want to change a feature at the last second after seeing that their own original design is crap even though we told them from the beginning. All of this is what makes crunch mode. Changed specs with a static deadline.

Re:Still common, but not intentional...

[bskin]

'Designing as you go' is the opposite of design. The whole point of designing is to plan out what you're going to do ahead of time. It's a shame more software companies don't seem to realize this.

Re:Still common, but not intentional...

[cratermoon]

Yes, if you design as you go, you get something like a beehive, a termite nest, or an anthill. And we know how how badly those meet the needs of their builders. Oh wait...

Re:Still common, but not intentional...

[Lonewolf666]

It can be done under certain circumstances:
1)The application is not too complex.
2)The project leader is good at designing on the fly AND has experience with similar applications, so he knows what works.
3)The team is small enough to work together closely, so the lack of careful pre-planning can be compensated by detecting mis-developments early. Usually goes hand in hand with 1)

Ignore one or more of these conditions, and disaster is likely.

Re:Still common, but not intentional...

[Taulin]

What has also happened to me several times is getting a project lead who doesn't mind working 100 hours a week, and changes things back and forth constantly. To the boss' eyes, he is a hard worker because he works so long, and it becomes a game every night to see if I can get out the door before he decides to switch something back.

Hey, if 24 hours a day isn't enough time...

[nganju]

Then work nights.

Crunch mode does not work in the Software industry

[Syncdata]

Crunch mode only works when it isn't de rigeur.
If a dev team knows they are gonna get stuck on crunch time beforehand regardless, they're gonna put off the crucial issues.

The video game industry is sick. From the devs to the phone monkeys, most companies prefer mandatory OT to sensible deadlines. As far as phone monkeys go, I know EA at least has a 6 month policy for employees. Right when the employee really starts to rock the party, they're cut loose.

Yes, I was a phone monkey in the day. EA could have cut half their support staff if they would have gotten rid of their 6 month policy, and started paying benefits. They would also reap the rewards of a competant workforce.

I hate to say it, but it's going to take unionization, and an industry wide strike to make them see the light. I'm no fan of unions, but this garbage needs to end, for everyones sake. The consumer, the company, and the employee

Hmmmm....

[RootsLINUX]

I'm contemplating e-mailing this to my advising slave driver^H^H^H^H^H^H^H professor...

Re:Hmmmm....

[Anonymous Coward]

Ha! You think academics is hard? LOL...

L.O.L. I SAY!

you can stop any time you like, you won't go hungry.

Re:Hmmmm....

[Anonymous Coward]

You didn't backspace enough! It still says "slaveprofessor".

Re:Hmmmm....

[Synbiosis]

"you can stop any time you like, you won't go hungry."

If you're a grad student? You make shit for cash, often times less than minimum wage. Unless you're a hot-shot with an NSF fellowship, you're living in a shitty apartment eating ramen and free food from department meetings.

Quit grad school? You'll lose your stipend. Now you're jobless, and more than likely with a degree that makes shit without a graduate degree in a poor job market. I'd have to say you'd defintely go hungry under those conditions.

Re:Crunch works. Death march does not.

[Merk]

The important word there is "days".

For a few days in a row, you can increase productivity, but based on this guy's research, shortly after that, you start to lose productivity to such an extent that after 2 months you would have been better off sticking with 40 hour weeks. In addition, if after those 2 months you go back to 40 hour weeks, it will take a while for people to recover from the 60 hour weeks.

So yeah, a "crunch mode" of a few days works. I would even guess that you can get away with 2 weeks of "crunch time", but beyond that, you're eating into your future productivity. But, even then, at 60 hours a week, the chance of a catastrophic error on any given day (accidentally nuking the CVS tree, tripping over the plug to the server, etc.) goes up dramatically. So even a short crunch mode is risky.

If a manager understood this, and only used crunch mode in dire emergencies, and then examined what went wrong so that it wouldn't happen next time... that would be good for everybody, managers, employees, everybody.

different metabolisms

[epine]

I have an odd metabolism where my body prefers long nights and long days (my cycle can range between 26 and 40 hours). If I'm well rested, I rarely witness a loss of productivity until 22 hours of wakefulness. Rarely at my best first thing in the day. I'm still gaining speed twelve hours later. For some reason, I go down like a rock after 28 hours of wakefulness and this has always been true. I've gone from near normal to "legally drunk" in the space of twenty minutes. I have far more problems with my body not being designed to sit in a chair for that length of time than I have with my mind falling apart. Unlike most people, I rarely allow myself to operate in a sleep-deprived state. Everything that article says about extended wakefulness is suspect because the studies didn't differentiate "rested" from "well rested" relative to how much sleep the body really wants as opposed to cultural norms (most people think that eight hours is luxury, and in the Army they expect to function on six hours routinely). There's plenty of research that shows that up to ten hours is needed to achieve the "well rested" state. Measure those people for task decay. You'll get entirely different numbers.

good read

[toad3k]

ug, this shoulda been on the front page.

Re:Good fucking lord.

[Anonymous Coward]

And what's with this "END COMMUNICATION" bullshit? Does he think he's TRON?

An Addendum

[LordZardoz]

Crunch time works when its used in the event of "Shit happens, and we need to get Task X done by Day Y". For that purpose, it does indeed work.

Crunch time fails when its used in an attempt to save money.

Death marches happen when a project is under staffed or under scheduled. Either someone did not want to pay for 2 or 3 extra programmers, or did not want to pay for a few extra months of development. So your left with a short fall of X amount of man hours to get the job done on time. So you put the extra burden on the other employees. Sometimes it can work. Sometimes it cannot.

Bad crunch time happens when someone gets greedy, or when someone screws up with time estimates for a project.

To put it most simply:

Crunch can be used to fix the mistakes of a dev team. It cannot be effectively used to fix the mistakes of management / publishers.

END COMMUNICATION

Crunch mode is inevitable...

[mutterc]

... because the market demands it.

Nobody will pay enough for software that isn't done half-assed, so you go with half the resource you need and slave-drive them to get it out when the customer wants.

If you push back at the customer, and say "you can have it in twice the time or at twice the cost", then they will just buy from someone else who accepts the constraints.

Also, if your company is publically-traded or has more than a few investors, their profits must continually grow at a continually growing rate. You can't just keep raising the cost of your sofware, so you need to keep the staffing levels low, so they spend all their time on death marches.

Clueful management can't save you... ours knows the stuff we're doing is a bad idea, but it's either that or go out of business now. At least if they hold on for a while then they might be able to cash-out.

If anyone believes there are software development jobs, anywhere in the world, not held to these constraints, let me know... I will sleep with whomever I have to to get one.

Re:Crunch mode is inevitable...

[MemoryDragon]

There is none... even in the public sector you usually have to fight for sane schedules... But at least after the crunchtime in the pub sector you usually can take the time off.

Re:Crunch mode is inevitable...

[startled]

"Crunch mode is inevitable because the market demands it."

It does? Funny, we must be in different markets. The market I'm in sometimes demands a superior product, or a lower price, or a quicker delivery. Those requirements are generally fulfilled by maximally efficient production: more quality and quantity produced for less time and money.

Now, if the market you're in somehow demands products completed well beyond schedule, or way over cost, or ridden with bugs, that's a curious challenge to current economic theory. You should probably get someone to study it.

Re:Crunch mode is inevitable...

[mutterc]

Have you examples from the software market? I'm particularly interested in this customer that would demand a superior product, but be willing to pay more and/or wait longer than for a sucky product.

Companies in such a market would easily attract the best and brightest of developers, as the work would be somewhat less sucky.

I don't see the clash with economic theory. Remember, what the market is optimizing for are successful (=increasing-profit) companies, not "good" products in an engineering sense.

• Competition = schedule and cost overruns as competitors scramble to one-up each other on bid outrageousness
• Lack of regulation = no floor on quality = bug-ridden
• Customer demands a superior product, but isn't willing to pay the price = promise superior product, deliver inferior one
• Disposable executives + stock-option compensation = short-term thinking = execs don't care if the company develops a reputation for not delivering on promises; they'll be somewhere else by the time that catches up with the company.

Are there any factors (that have ever been instantiated in the real world) that work against those four?

Re:Crunch mode is inevitable...

[startled]

Have you examples from the software market? I'm particularly interested in this customer that would demand a superior product, but be willing to pay more and/or wait longer than for a sucky product.

Well, the game software market is full of examples (Blizzard). It's quite different from the software market you're discussing, of course, but it's also plagued by crunch time, and tons of horrible, bug-ridden crap.

Packaged software in other arenas also has some examples: businesses will choose between, say, Maya and 3DSMax based on price, quality, and current needs. (Quality, as you pointed out, being difficult to quantify: they may be shit engineering-wise, but people in all areas make poor quality judgments all the time.)

It seems that the problems you're referring to are much more prevalent in contracted or internal software development which, admittedly, is a cesspool right now from all I've heard.

Disposable executives + stock-option compensation = short-term thinking = execs don't care if the company develops a reputation for not delivering on promises; they'll be somewhere else by the time that catches up with the company.

This seems like a separate problem to me, and I agree it's a very large one. It plagues all public companies, and leads to some behavior entirely contrary to what one would expect if one were under the impression a company would act to sustain itself.

Just refuse

[bluGill]

Just tell your boss no. I will work overtime when a customer runs into a critical bug in the field. I will work overtime once in a while when I don't already have plans, and there is on feature that I need to finish. I will work overtime when there is someone in from the main office explaining something. I will not work overtime because you refuse to cut some features from your over aggressive schedule. Course you alone isn't enough, then can get rid of you. Have your co-workers do it too.

When you allow yourself to be pushed around management things you are spineless, and they will push. When you stand up to the bully they find someone else to pick on.

I have discovered that I do not have even 8 hours of good code per day in me. I end up spending a at least an hour a day doing non-code things (and there are plenty of them) to make up.

Death Marches

[sesshomaru]

I thought that a 'Death March' was a project that was doomed and couldn't be salvaged. Usually, there are political reasons for not shutting it down, so since management can't cut its losses, it just throws bodies and hours at the project until the last extremity is reached. At which point, the company has gone out of business or the people keeping the doomed project alive are fired and replaced.

Crunch time at EA doesn't fall into this category, because apparently the projects sell well enough to keep the most evil company in the history of gaming squatting on top of the market like some poisonous, evil toad infecting other companies with its toxic bile.

Re:Death Marches

[beesmum]

It's a bit offtopic and I should really save it for a thread dealing directly with EA but I want to weigh in with my first hand experience of the evil bloat that is EA. I had the honour and privelege of maintaining the top execs property in Vancouver while I was working there as a gardener.

The fellow was nice enough, but he'd made enough from EA's growth throughout the nineties to buy the three massive properties around his gigantic house and property and was developing them into a huge super property. It was unbelievably massive, to think of millions of EA peons breaking their backs so that the gent on the top of the heap could live on his own personal little resort in the middle of one of the most expensive areas you can live in Canada.

I know its not much different than any CEO of a megacorporation but I think it puts into perspective in a tangible way how tech labour is parallel to labour during industrialization, unregulated and lacking unions leading to the exploitation which keeps coming up lately.

This is why crunch mode happens

[alvinrod]

Crunch mode apparently happens because game developers and others in the industry are screwing around on the clock instead of coding ;)

This problem didn't start from nothing...

[OverDrive33]

No one can seem to figure out where this "crunch time" for programmers came from.
Frankly I'm surprised no other slashdotter's pointed it out: Programmers want to be 'leet'.
I remember starting to learn how to program about 9 years ago, I used to brag to friends about how I stayed up all night coding - a few people were even impressed by the fact I hadn't slept in 48 hours and made this cool little game.

Now we're all getting older. Young programmers (IMO) will tell any employer "Oh yeah, I can code for days on end, I'm a leet code haxor". And even if a young programmer tells a potential employer that he can't work 50+ hours a week, the next young programmer that comes for his interview will.
I have a feeling upper management of these game companies know this and exploit it to their own ends.

ALL programmers have to wise up and realize that their best code comes not after staying awake for 50 hours while running on 4 cans of Jolt cola, but after a relaxing sleep (it's a fact!).

Re:This problem didn't start from nothing...

[chthon]

I already found out when I was 21 or 22 (I was still in school then), that it was better for me to go to sleep early, rather than stay up late for a programming problem.

When I woke up fresh, I usually had the solution of the problem the evening before, and it was much easier to spot problems in already implemented code.

WTF? Where did the OP say "In IT" anyway?

[baadfood]

um, thats why the original article totally failed to specify crunch mode in IT.

Well...

[BluffBlank]

Maybe if slashdot wasn't here, we wouldn't spend half the day reading it, and crunch time wouldn't be needed at all.

Re:75 Years? WTF?

[marcello_dl]

You could have crunch-read TFA...