Crunch Tactics a Symptom of a Larger Problem?

An anonymous reader writes "One of the brave few: hot on the heels of the recent lawsuit filed against Vivendi Universal for back wages due to a developer who was allegedly asked to alter his timecard, Rob Fahey of gamesindustry.biz has taken the bold step of taking the position that the insane hours game developers are routinely asked to work are might not be in the industry's best interest, and in fact might be less profitable than planning projects well."

Comments

This is, like, news?

[grm_wnr]

Yeah, who would have ever thought of that? The fact that this statement is seen as "bold" should be indication enough that something is amiss here.

Re:Already addressed; Solution proposed

[JavaLord]

The game industry is finally coming to terms that the long work hours caused by inadequate planning and management is driving away many talented workers and programmers.

If you are a member of IGDA I'm sure you know that there is no lack of programmers that want to work in the game industry. The problem is the game industry has no method to bring in programmers who have experence programming, but not programming games. Basically you need a CS Degree, plus a hell of a working demo to get hired somewhere and the jobs are very limited. Once you are hired, and you are good enough then you can hang around, but most people in the gaming industry are very good programmers and at some point after working 80 hours a week they are going to say "I don't need this shit". Lack of programmers who want in isn't the problem, lack of an ability to keep them in might be.

Maybe if the gaming industry brought on more low level programmers at the start of a project, they would have enough people so insane crunch time wouldn't be as insane. Of course then they would have to pay their salaries, which gets in the way of Profit!

Re:It's like this for any programming project.

[egomaniac]

Anyone who has ever worked as a programmer can tell you that as a deadline creeps up they usually end up working more hours. Spec's change, deadlines get moved up and back, other developers quit, etc.

...

Unless you give yourself an extra 6 months to a year of slack time, you are always going to have suicide hours near deadlines because shit always happens.

Then you plan for that and include it in the schedule. If it "always happens", then you'd better always include it in the schedule. There is no excuse for doing otherwise -- forty years of software engineering history gives us a pretty strong indication that the belief "maybe everything will go perfectly this time" is a horrible fallacy.

Things will go wrong. Specs will change. People will get sick. It happens every fucking time, and we all know it. So what the hell are we doing not building this time into the schedule? Not doing so is equivalent to jamming your fingers in your ears and yelling "la la la, I'm not listening!" at the top of your lungs. It might feel good for a little while, but it's bound to bite you in the ass later.

At my company (not games, but trust me, you've heard of us) we routinely double or triple all time estimates provided by engineers, to account for unforeseen eventualities. Wonder of wonders, my team has always hit our dates and we don't have insane crunch time near launches.

Obviously, truly earthshaking events -- building burns down, lead programmer hit by a bus -- can throw even the best schedule off. But surely we can be doing better than having the schedule thrown off every single time we build something, can't we?