Quality of life at Blue Fang!

[Mike D Smith]

Just read an awesome article in the January issue of Game Developer by Hank Howie. It's called "Making Great Games in 40 Hours per Week". Finally someone in the gaming industry that understands employee productivity and management responsibility! A must read for anyone who wants to change the way things are. It almost makes it look worthwhile to give up the the indie route and work for someone like Blue Fang... I said almost.

[Sirrus]

Nice to know considering they are practically down the street

[Dan MacDonald]

I couldn't find this anywhere in the print version... got a page number?


Ahh I was looking at the December issue...

[kerchen]

I think many companies attempt to do the same things described in the article, but when push comes to shove, it's either work harder and get paid or work "normal" hours and don't get paid. Towards the end of the article, the author admits they had to work 26 days solid to make their deadline. As long as games remain a creative endeavor, there's always going to be crunch time. In the same issue of GD magazine, there was a Sims2 post-mortem which stated that, at its peak, there were 140 developers on the project. With a project that size, I don't know how you *couldn't* have some bad crunch time--keeping that many people on the same page for 6 months (let alone 3.5 years, though they weren't *all* around for the whole project) is quite difficult.

One of the things that attracted me to the company I now work for (www.stardock.com) is that they have had very little crunch time in releasing their previous titles, but if a situation arises wherein the company stands to lose a lot of money if the next game isn't out by some date, I fully expect that the situation will change. Yes, we all want to make sure we have reasonable schedules and milestones, but sometimes the best laid plans go awry and next thing you know you're staring at code on a Saturday night (and not for fun).

[EpicBoy]

As long as games remain a creative endeavor, there's always going to be crunch time.

There's a difference between, "Putting in extra effort because you want the game to totally rock" crunch and "we're working 80 hour weeks because management couldn't plan properly" crunch. The latter is what concerns people.

[Coyote]

When I was at SingleTrac, we had a lot of the former and very little of the latter. In fact, it was only towards the end that management began to encourage extra hours - but I only remember it being mandated about twice.

The first year or two there were really psycho hours - I remember vividly walking in from a bathroom break into the office area and realizing that people were working hard at almost every cubicle - just like mid-day... except it was shortly after midnight.

But we weren't burned out then, and there was a huge feeling of personal ownership in our products and in the company itself. And we also knew if we failed we'd probably be out of a job in nine months.

Later, when I got a job at Acclaim, I discovered one of the teams had been on mandatory 60+ hour weeks for SIX MONTHS STRAIGHT. By then, I'd begun reading up a bit on software engineering methodology and management, and had reached an opinion that crap like that was due to a complete failure of management. At that point, I began looking at other opportunities outside the games business. Unfortunately, this type of crap is hardly unique to game development houses. I was at another company just recently - we'll just say they are a really big multinational publisher of personal and enterprise-level software that's (but not Microsoft big) that wasn't quite this bad - but close - and then thanked the entire team by laying them all off three or four weeks after they got the product out the door.

Give your employees enough incentive that they'll be willing and enthusiastic to pull out all the stops for you --- but mandatory overtime should be at the very bottom of your bag of tricks. It's only marginally effective in the first place, and then only for short bursts.

[kerchen]

There's a difference between, "Putting in extra effort because you want the game to totally rock" crunch and "we're working 80 hour weeks because management couldn't plan properly" crunch. The latter is what concerns people.

Yeah, that difference is about five years in the biz. As devs get older, the allure of crunching for any reason is diminished. If you have to put in extra effort to make the game totally rock, then by definition *someone* couldn't plan properly, though maybe it's not always management (management wants the game to rock too, right?). It seems like a lot of people think that when a project requires 80 hour weeks to finish on time, that it must be solely because of mis-management. However, every project I ever worked on at Maxis came with an estimated schedule early in the project that was made, in part, from my own estimates of how long stuff would take. And, even with padding and doubling and all the other scheduling rules of thumb, the schedule always ended up being off, resulting in crunch time. It's the nature of the beast. If I sign off on "an aggressive schedule", can I really blame management when it doesn't happen? Now, if you're in a situation where you don't have any say in the schedule, well, *now* you've got a management problem, but I don't think that happens very often any more, does it?

[svero]

Crunch time is definitely an artifact of poor project management in most cases. It's not something unique to games by any means. I've seen plenty of crunches in other kinds of software companies and it's almost always a result of poor planning. I don't think I've ever seen a case where management decided to force a crunch like deadline to save money by having people work for unpaid overtime, although I guess I'm cynical enough to believe it could happen that way. It's definitely possible to create a great game with reasonable hours and little or no stress time if it's planned correctly. It might even be better that way in the long run, as developers who aren't under a lot of stress and who are well rested and working at top capacity probably produce better work.

[Deutus]

Crunch time is definitely an artifact of poor project management in most cases. It's not something unique to games by any means. I've seen plenty of crunches in other kinds of software companies and it's almost always a result of poor planning.

This exactly is my experience, too. For software companies in general.

I don't think I've ever seen a case where management decided to force a crunch like deadline to save money by having people work for unpaid overtime, although I guess I'm cynical enough to believe it could happen that way.

I've worked for a non-game company once which did what you say (they saved money by "crunching"). I think it's no seldomness.

It's definitely possible to create a great game with reasonable hours and little or no stress time if it's planned correctly. It might even be better that way in the long run, as developers who aren't under a lot of stress and who are well rested and working at top capacity probably produce better work.

Again 100% true.
However I'm not sure if many people in the management / project lead recognize this fact because in order to do so, you've to take into account the future (like when playing Chess you've to think forward several moves) and I don't think our current industries/societies are good at this, because only the "today" counts, ie the fast success of today at the expense of the future.

[jofferman]

In my humble opinion, the prevailing myth is that overtime (paid or unpaid) is an effective means of increasing productivity and getting a project back on schedule. My experience is that, in many cases, forced overtime actually decreases the productivity of employees!

Unfortunately, overtime cannot always be avoided - but it's a tool that should be wielded with much care.

Jim.

[svero]

What amazes me in a lot of software companies is that companies pay big bucks to hire talented programmers and artists and then dont bother removing all the obstacles those people face regarding writing code. Little is done about noise, meeting interruptions, lunch, personal banking etc... A good software manager would do his best to pave a road where the more expensive employees could spend their time programming. Hire a lackey. Get a guy who can run to the bank for the 80k a year programmer leaving you in a position where he doenst take 2hrs off to stand in line somewhere. There's a lot that can be done in a cost effective way to improve overall company output. The last company I worked for as an employee has a chef on premises who cooked lunch for everyone. There's one example.

[EpicBoy]

Kerchen

Well, the way to tell the difference is this: Ask yourself why you're in the office at 3am - is it because you're adding extra stuff to the game to make it kick ass, or is it because if you aren't there the game isn't going to be shippable when the drop dead date arrives (meaning, you're rushing to get the basic game up and running)? If it's the latter, somebody screwed up the schedule.

Now, if you're in a situation where you don't have any say in the schedule, well, *now* you've got a management problem, but I don't think that happens very often any more, does it?

Are you being sarcastic? I don't think many employees have a say in their projects schedules...

[EpicBoy]

It's definitely possible to create a great game with reasonable hours and little or no stress time if it's planned correctly.

FYI, I have a friend who works at Valve and he told me that there was no crunch on Half-Life2. People worked basically normal days right up until the end.

[svero]

Sometimes what happens is that a game is developed according to schedule but then you see the result and realize its not as good as was hoped for and you schedule in some changes. That kind of thing can cause havok with a hard deadline and force crunches. I think it's probably best not to have hard deadlines for final release of a creative work, but rather to have a series of smaller deadlines that move the project along.

[Coyote]

Sometimes what happens is that a game is developed according to schedule but then you see the result and realize its not as good as was hoped for and you schedule in some changes. That kind of thing can cause havok with a hard deadline and force crunches. I think it's probably best not to have hard deadlines for final release of a creative work, but rather to have a series of smaller deadlines that move the project along.

Exactly. Feature creep isn't necessarily a bad thing in a game - and while I wouldn't make the claim that games are works of art, but developing interactive entertainment products is as much art as science. Changes HAVE to be made as the project evolves, and that will impact the schedule.

The problem is that with a major game release, there are so many parts of the process that have to move in tandem that hard dates are - at least by the current system - really mandatory. You have to have so much lead time to make sure that marketing reaches the apex just as the game releases, and that you aren't conflicting with another game release by the same publisher at the same time. You need to coordinate with distribution and your sales channels, because THEY want to know exactly what will be available to stock on their store shelves. You need to coordinate with manufacturing, legal, etc. for duplicating the media, printing manuals, producing boxes, and making sure they are all shipped and distributed at the right time. And of ultimately you've got a chain of management leading to the CEO who is directly responsible to the stockholders who want to see the most immediate short-term gains.

The alternative would be that the game has to be finished four to six months before it is actually released.

Of course, there are other alternatives, too - like what we indies do.

I think that short spurts of "crunch" - particularly if they are employee-driven, aren't a bad thing. A couple of weeks of heightened effort to make sure you meet a deadline or really polish up a milestone isn't necessarily a bad thing. But if you realize that you are two months behind when you are only four months into the schedule - anything so extreme that would mandate the kinds of psycho crunch that's FINALLY come under scrutiny - that says you have a really EXTREME management problem. You've got one or more things going on (as a manager):

#1 - Your time estimates are all about 50% under the mark. You either need to re-design the schedule to be realistic (and accept blame for screwing it up so bad), hire more people, contract out certain tasks, and / or reduce scope significantly.
#2 - Your team motivation and morale is so incredibly low you you are only getting about 65% of their normal productivity. You need to find a way to improve motivation and productivity.
#3 - There are some serious obstacles blocking productivity - like a major bottleneck in your critical path - that requires removal (possibly by redesigning the production pipeline to remove the bottleneck)

There are more possibilities, of course. But that's thinking like a programmer and trying to 'debug the system.' Overtime is a band-aid, but is worse than useless when you've got a sucking chest-wound.

[ManuelFLara]

FYI, I have a friend who works at Valve and he told me that there was no crunch on Half-Life2. People worked basically normal days right up until the end.

Well, not everyone has as much money as Valve. I mean, IMO crunching exists because if a developer doesn't reach a deadline they don't get paid by the publisher , but Valve, id software and this kind of companies don't have that problem because they fund themselves.

[Cartman]

I agree completely with the consinsus that bad management and schedules can cause many of the problems the industry has. In business development I've also seen many programs cause their own problems by underestimating the time they need to complete tasks. Sometimes it's because they dont' like to speak up (and I've met alot of these people in the industry), or they don't want someone else to look better by giving a lower estimate, or they don't give an estimate at all and let the program manager make it for them.

I had one friend of mine that always estimated too low, so his manager just started adding two weeks to everything he estimated. This actually helped him to meet his deadlines.

Some of the reasons for the problems in the game industry also seem to relate to good talent being driven out of the industry by the work load. I've meet peopel that moved over to business development from games and are very happy with the less hectic pace. With all of the talent being evacuated from the building, how are you going to learn from your mistakes and make the environment better?

[EpicBoy]

Well, not everyone has as much money as Valve. I mean, IMO crunching exists because if a developer doesn't reach a deadline they don't get paid by the publisher , but Valve, id software and this kind of companies don't have that problem because they fund themselves.

This is true to a point. However, from what I was told, Valve set very reasonable deadlines and they hit every milestone along the way. They weren't doddling around for years and not getting anything done.

If you create a sensible schedule, you can hit it. Simple as that.

[Martoon]

In my humble opinion, the prevailing myth is that overtime (paid or unpaid) is an effective means of increasing productivity and getting a project back on schedule. My experience is that, in many cases, forced overtime actually decreases the productivity of employees!

Absolutely. I think the really naive manager sees the relationship between hours worked and productivity as being linear (if people get this much done with 40 hours/week, then they'll get twice as much done with 80 hours/week, etc.). A slightly more informed manager might see the productivity to hours relationship as a logarithmic curve, or maybe a curve that converges on some maximum (you get diminishing returns on added hours, but still, more hours yields more productivity). A truly enlightened manager will realize that it's actually a curve that slopes up, levels off, then heads downward again (if I make these people work any more hours, they'll actually get less done), especially when thinking beyond the next week or two.

[gmcbay]

This is true to a point. However, from what I was told, Valve set very reasonable deadlines and they hit every milestone along the way. They weren't doddling around for years and not getting anything done.

One of the online gaming sites (gamespot?) did a post-mortem and unless the article was total fabrication, Valve seemed to have had a really sketchy development cycle for HL2. One that included tossing out almost everything they had and starting from scratch at one point... plus a lot of crunch at the end.

Unfortunately, I don't recall the link offhand.

[EpicBoy]

I doubt my friend was lying to me. He'd have no cause.

[Greg Squire]

FYI, I have a friend who works at Valve and he told me that there was no crunch on Half-Life2. People worked basically normal days right up until the end.

Nice to hear that there are still some sensible companies left in the industry. I hear way to many horror stories like the ones coming from EA lately.

[svero]

Well, not everyone has as much money as Valve. I mean, IMO crunching exists because if a developer doesn't reach a deadline they don't get paid by the publisher , but Valve, id software and this kind of companies don't have that problem because they fund themselves.

This might be the case sometimes, but from what I've read some of the worse places for unpaid overtime are the publishers themselves. You're not going to tell me the people working at EA are crunching because EA is about to run out of cash and has to meet it's own deadline are you?

I don't really think this is a money issue. It's not good financially to plan a project poorly. If you promise to deliver something to a publisher and you can't meet that deadline because you've bit of more than you can chew, it's quite likely that neither your employees, the publisher, or the game's audience will react well to the final result.

[Ricardo C]

One of the online gaming sites (gamespot?) did a post-mortem and unless the article was total fabrication, Valve seemed to have had a really sketchy development cycle for HL2. One that included tossing out almost everything they had and starting from scratch at one point... plus a lot of crunch at the end.

Unfortunately, I don't recall the link offhand.

Gamespot has a series called "Behind the Games", but they haven't covered Half-Life 2. The piece you probably refer to is about the original HL, which did have a tortuous dev cycle.

[Mike D Smith]

I think one thing people often overlook in the 40 hour work week is that to make it work, your employees really have to work hard core durring that 40 hours. No sluffing off or shooting the breeze.

It's really sad, but this kind of sluffing off is often accepted where something like working hard all week long and refusing to work on Saturday is not.

If an employee does 6 "real" hours of work each day, after 6 days, they still have not done as much as the guy that worked hard for 5 days.

Then again, sometimes it doesn't matter how much you get done in the 40 hour work week. If your ahead, you haven't added enough new features yet.

[luggage]

From a developer's point of view crunch time is always the fault of management.

Seems a bold statement but it's true. No matter what happens on a project only management can do something about it. Here's some examples of crazy decisions I've had to endure...

* Publisher decides to change the genre of a game halfway through but still want the game done to the same deadline. The developer's management agreed.

* Scheduled tasks for the rest of the project. When the amount of days required went over the amount of days left management decided we can't have that. They then went through the schedule chopping days off everything until it fit.

* When asked how long something will take, I answered 5 days. Management said it had to be done in 2.

* Scheduling how long a project will take by calculating staff work time as 9.30am till 10pm and having no time off for an entire year. They didn't even allow for weekends, sick days or holidays.

* Agreeing to features requested by the publisher before asking the dev team how long they'd take to implement. So you get the situation where they want the game networked and management said it would take a week when in fact it would take a lot longer. And where management turn down ideas like 'another enemy' which would take all of a day to put in but they never bother to ask.

* Not caring how much work you do so long as you're at your desk until at least 10pm.

Crunch time is needed when you have a deadline that you're not going to meet.

If the original deadline was too short then management should have done something about it (chop out features, renegotiate with publisher, etc).

If the staff aren't pulling their weight during normal work hours then it's up to management to have a word with them, or replace them.

If the staff are working well during normal hours but are still drifting behind then they need to get more staff in.

There may be times when crunch time is needed. We took on a project once where the original developer had spent a year and got nowhere. We were handed the project, had to start from scratch and had 3 months to write a PS1 and PC game. If that's the case then the publisher had better be paying well and some of that money should find it's way to the staff working on it.

It's not just the long hours that get you down - it's the fact you quite often don't see anything for it. Working 9.30am till 5am for 5 months, including weekends, and not getting a penny extra isn't the best way to get work out of staff.

And as someone pointed out, too many managers think working twice the hours = twice the work. There was a test done and I think it was something like an extra hour or two was the most you could get out of staff. After that you start to have a negative effect.

Once I worked until about 3am, had a problem with a section of code I'd just written, went home and came back in the next day. The section of code I had done was about 7 lines long, literally just a for loop and iterating through a list. There was a mistake with every single line, and multiple mistakes on those lines. This frightened me

[gmcbay]

Gamespot has a series called "Behind the Games", but they haven't covered Half-Life 2. The piece you probably refer to is about the original HL, which did have a tortuous dev cycle.

Nope. The one I am talking about was Half-Life 2 for sure.

Re-found it here.

It paints quite a different picture than EpicBoy's friend's ("When the team returned to work in January 2004, it had been in crunch mode for almost a year.").

Having no inside information, I have no idea which is closer to the truth.

[EpicBoy]

Again, he has no reason to lie to me.

[BongPig]

Ive been badly mis-quoted so many times that I cant believe anything written by any gaming websites/magazines.
...so, Im inclined to believe EpicBoy.

[EpicBoy]

Geoff Keighly is a respected journalist and is very good with these types of articles ... on the other hand, "everything was pretty laid back and we didn't crunch at all" doesn't make for a very entertaining read.