Slashdot Mirror
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."
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....
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.
Damnit - I wanted my nick to be "WouldIPutMYRealNameOnSlashdot"
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.
Plays violent online games as: Nerfherder76
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
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.
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.)
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.