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."

Yeah, right

[c0ldfusi0n]

Tell that to EA Spouce [livejournal.com], she knows.

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: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: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: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 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.