Anti-Crunch Strategies

Management is the key, and ultimately responsible for any crunch time.

The leads and producers need to understand the capacity of their workers, be able to estimate and schedule well, and vigilantly fight scope creep up to and including the last day. They need to push their team. They must be able to prioritize all the tasks involved in making the game. They need to coordinate schedules and plans with the non-developers. Execs will try to force new features on you up to and including the day of final submission; the leads need to fight that off.

Daily status reports are important to make sure that people are doing what they are supposed to do. (As discussed in previous threads, it is "daily nagging") Properly partitioned tasks with daily measurable milestones are very effective.

In my experience if the management does well with those then the crunch will be very mild.

Note that there is still a crunch time. The crunch is to fix all the bugs and add the last tiny bit of polish and tweaking before shipping. There is always "one more thing" that you want to do.

My current project has been managed well and has had almost zero crunch. There was a standing request that people stay a few extra hours for a few weeks if there was nothing pressing with home and family. Most of us spent a few days here until 8 or 10, with some people staying past midnight a few nights by their own choice. We had some nice incentives to get extra work done (ahem) but otherwise it has been very low stress.

I spend about 8 hours a day (sometimes including weekend and sunday) in front of PC and my working hours usually spread unevenly throughout the day with multiple breaks. No crunch time for me unless somebody points a gun on my forehead .

We have a project plan which is as complete as possible (obviously it's
impossible to plan everything 2 years in advance without missing a
single task) - All tasks are divided over all programmers and every
single person gave estimates on their tasks (and the lead adds 25% on
these estimates :)

Besides that, every 6th week in our project is a 'recap' week.
That means that there are no tasks planned and it's mainly used
for fixing bugs and catching up any lagging tasks, or doing
unforseen tasks.

This avoids the 'big bughunt' at the end of the project, and since
there is time to really take a look at the bug and fix it (as
opposed to making a quickhack to 'make it go away') the codebase
doesn't degenerate.

As longs as the people actually doing the tasks give time-estimates
(and not management), the plan is actually quite accurate.

I have to say that the Gantt chart in MS Project has been the bane of my professional game development life:

Producer Without a Clue: We need to finish the project on date X. You've been assigned A, B and C. How long will they take so I can put the time in the plan?
Me: Well, what exactly is A?
PWC: It's A, you know. Can't be that hard.
Me: Is it a small A or a big A. How does it talk to B and C. Does it need to talk to D? Where does it get its information from?
PWC: Can't you just make a guess? Oh, and make it come in before X.

Skizz

list all you requirements and prioritize them by their importance and size,

don't have more than half of your time dedicated to the core requirements, ideally only one third, the rest of the time to requirements that will make the product better but wont ruin it if they aren't finished,
also don't save all the testing until the end, as soon as you have the core of your product working test all new components as soon as their complete

even if you don't want to go for a full blown iterative design methodology try reading about a few of them

the basic philosophy is that even if you get you timetable slashed you'll have a minimalistic product instead of a useless barely-functional buggy product

Quote:

Original post by Kaze list all you requirements and prioritize them by their importance and size, ... the basic philosophy is that even if you get you timetable slashed you'll have a minimalistic product instead of a useless barely-functional buggy product

As I mentioned above, that ability is the key in avoiding a crunch. Well, that and pushing/nagging/influencing the workers to actually work.

There are always features I want to add. And it isn't just my own projects, I look at other games and think "I wish it had feature X". That's part of what makes a good game programmer. This week I'm reviewing a bunch of camera code. There are so many camera modes I would love to add. Having researched it, I can think of so many ways to implement the TDDs that would be spectacular. But I only have one week, so I'll stick with the core items, reply to a few gd.net postings, and maybe get two or three of the optional content done.

Curse you GD.net! Now this (AAA) game will have two less functional cameras! [oh]

That is where the trick to crunch times lies. The development leads and management MUST differentiate between what is nice to have, what is important, and what is critical. They need to get the critical stuff done well and schedule properly for it. That scheduling needs to include people looking at gd.net, watching youtube movies, and otherwise wasting time. They need to schedule properly to ensure they get many of the important things in, and (unfortunately) will generally end up discarding nearly all of the nice-to-haves.

This is one reason that so many indie projects fail. They focus on the nice-to-haves because they are fun. They avoid the critical stuff because it is often hard work and they can't prioritize it.

We are a startup company in a developing country so we crunch to first position ourselves in the market. Until we do so, we cannot afford to work normal times.

As studio head, I am the first to come and last to leave. Because I have to manage employees, freelancers and outsourcing teams from different time zones and sleeping patterns, I spread my time into different segments.

This is a typical day:

5:00 AM - Wake up, check e-mail I wont reply e-mails, but just to have something to think while walking. Office is near, I walk to office.

5:30 AM - Reply urgent e-mails. Reply IGDA and GameDev forums. If have time reply emails of lesser priority.

*In between I smoke at least 3 sticks.*

8:00 AM - Breakfast with game designers, lead artist, associate producer.

9:00 AM - "regular" employees appear.

10:00 AM - Reply associate producer's e-mail regarding tasks.

*important / urgent work happens here*

2:00 PM - Reply important e-mails received in the morning.

2:30 PM - Meet with "regular employees" regarding work.

5:00 PM - Meet with Leads

*important work happens here*

7:00 PM - Dinner & arcade

8:00 PM - Voice conference

Sleep occurs anything from 10pm to 2am. Sometimes I don't sleep but that is if there is an emergency.

We are launching a game early March. My employees work at least 12 hours a day now.

I'm just starting up too but I completely disagree with everyone crunching to position the company. Employees shouldn't have to suffer for your company and your success.

Fair enough, I should work long hours. My company, my survival, my rewards. I'm technically doing two jobs (programmer and business) and I'm only able to do that because the jobs are so different it's refreshing to alternate. I do the getting up early thing, program on the morning before people have even woken up, and do business stuff and dealing with people on the afternoon when more of the world seems to be awake. Then a mix of both on the night if needed.

If you have employees working 12 hours a day every day they will find ways to avoid work (coffee, toilet, smoke). They'll spend too long messing around on the internet before starting. When they do work they'll make mistakes. The amount of productive work you'll get will not be in proportion to the extra man-hours.

True, there are ways to make them work harder and not play during hours. This will only increase the time that they will burnout and you'll have to look for new staff to line up before the whip.

It'll be harder to get people to work with you if you build up a crunch reputation! You'll lose the talented people you already have to burnout, other talent will take better jobs before yours, and all you'll be left with are the mediocre people who have to accept the crunch because they can't get a job anywhere else.

It's a horrible downward spiral yet I see it happening all the time in small and large companies.


I take a completely different approach with employees/sub-contractors. For a start, I avoid taking on creative people (even programmers) full-time for a single project. Rather than employ one person to work all week 9-5 on a project, I prefer to get two people for the same wage sharing the hours. You get the added bonus that they may have different specialties and two heads are better than one when it comes to creativity.

Not being full-time allows the workers to follow other pursuits. A lot of people have their own personal projects and the work I offer semi-funding them. Others have more than one contract but prefer the variety (I'd happily employ them all week as long as it was on more than one project and I thought they were happy too).

They become the masters of their own weekly schedule. If they feel they've taken on too much then they can take less, or less time consuming, jobs in the future.

I'd rather have a very talented person working for me for 2-3 days a week, than someone less talented all week. You lose the Monday blues, the mid-week slog, and even that Friday feeling. The hours they spend is efficiently spent.

I feel that one of my most important jobs is to decide how much work people can handle and 'should' be able to handle. I'm also in a good position that if they don't live up to their promises and their peer they can choose to put more time into the project. Either that will be a lesson learned in efficient timekeeping, or I can re-adjust their next job to be less time-consuming but for less money, or simply not employ them again if they strike out too often.


To concur with many people ...crunch bad ...if crunch, management bad ...management bad, you fail.

Honestly, you have a point.

I will talk to my employees and sub-contractors. Truth is they all seem to tell me that they are happy.

Lots of developers "like" to work long hours, its known as the hero mentality. They think they are being a hero by working so hard. Truth is that if you work long ours for any length of time you become less efficient and end up being in the office longer but producing less (and of a lower quality). Because your brain becomes tired you make more mistakes and those mistakes become harder to fix. It is actually better for them and for you if they work reasonable hours.

Quote:

Original post by Obscure Lots of developers "like" to work long hours, its known as the hero mentality. They think they are being a hero by working so hard. Truth is that if you work long ours for any length of time you become less efficient and end up being in the office longer but producing less (and of a lower quality). Because your brain becomes tired you make more mistakes and those mistakes become harder to fix. It is actually better for them and for you if they work reasonable hours.

if i remember correctly in my project management book its said overtime offers some increased productivity in the short term but after about a week the gains drop to almost nothing as people get worn out
because despite your best efforts you probably will end up with a crunch or worse a unforeseen problem may arise just before the release date it is extremely dangerous to the project to burn out your staff before crunch time

I have talked to my guys and they want to work long hours until BETA. I gave the green light only after I told them that they have to take 5 minute breaks every hour.