Sustained periods of overtime have long been considered "normal" within the game industry and are often considered a prerequisite for creating quality games and meeting deadlines. Some developers go a step further and view working brutally long hours as a badge of honor and something to be admired and respected.

In an attempt to better understand the prevalence of overtime in the game industry, I reviewed 30 Game Developer Postmortems from the past five years.

Of the 30 I reviewed, only five specifically cited arduous hours and overtime as both regrettable and something to be avoided in the future. Nine implied that there had been serious overtime, but made no mention of it as being either regrettable or avoidable. One of those nine described the practice of their employees working 24 hours straight, sleeping six hours on site, and then working another 24 hours as "fostering a hardcore work ethic." The remaining 16 Postmortems made no mention of overtime. Given what we know of the game industry, I think it's highly likely that a fair portion of these projects entailed some form of crunch time.

The winds of change constantly rush through this industry, and the issue of quality of life in game development continues to gain visibility and momentum. Continued pressure from disgruntled employees, the outcome of the Vivendi and EA lawsuits, and the impact of new federal and state overtime laws may drive legal action and force some developers to limit their staff overtime or face additional compensation expenses.

While the prospect of limiting staff overtime may be frightening to some, it's possible to make high-quality games without severe or extended crunches. Great games can be developed in something resembling a 40-hour work week schedule. How is this possible? With appropriate systems and infrastructure in place, employees who work relatively steady 40-hour weeks are demonstrably more efficient and productive, especially over an extended period of time, such as that of a standard game development cycle. The bottom line is that through effective management and policies, development teams can get more done in less time.

This is not just a hypothesis; I've seen this principle successfully applied to software development in the game industry and in other software businesses. The most effective and successful software development managers I have worked with understood that performance degrades with prolonged work cycles and lack of sleep. Early in my career, I asked a successful development manager why he was sending people home as opposed to letting them stay and get more work done. His reply was simple: "These guys have been working hard, I know they've been here for quite some time, and I don't want them checking in buggy code." The benefit gained from the extra time spent at work was often outweighed by the cost of increased error rates and the lower overall productivity of a tired and potentially demoralized staff.

His philosophy has stuck with me, and I've seen this principle at work in our game business. Our company, Blue Fang Games, has been in business now for over six years. We've collaborated on one project, shipped two full games and two expansion packs, and we've always taken pride in our ability to make great games while hitting our milestones and shipping our games on time and on budget. Through all of this, our company policy has been to let our employees have their weekends to themselves, actively and successfully discouraging any sort of incessant overtime.

How do we do this? For the most part, it's the application of tried and true software and project development procedures and techniques, combined with what we believe is - or should be - common sense.

Make it a Priority

First, keeping people's hours reasonable must be a company priority. I submit that it should be one of your company's essential values. Otherwise, and especially if it hasn't been a key value to date, when confronted with a difficult situation, it'll be too easy to backslide into old habits. At Blue Fang, we've made it a part of our mission statement:

Thorough Planning

Next, you need to be very thorough in the pre-planning and planning phases of your projects. Planning is perhaps the most critical time for any game's development, and this is where most schedules go awry. Whether you utilize the classic "design, estimate, schedule, and build" methodology, or are using more of a prototyping methodology, if you and your team are not painstakingly thorough here, you will not be successful at maintaining your schedule and keeping your team's hours reasonable.

There are some basic planning guidelines that we adhere to here at Blue Fang. First, someone must be functioning effectively as the builder and keeper of the schedule, in our case, the producer. This person has to be detail-focused, persistent, and patient. You are fighting an uphill battle in the planning stage as the natural inclination of everyone on the team is to get through the boring and tedious estimating and scheduling portion of the process as quickly as possible. The team wants to be coding, creating real artwork, and designing. While the design work should essentially be complete at the planning stage (keeping in mind that some changes are inevitable), no real coding or artwork should be done until the job of task estimation is done.

The truth is that during the planning phase, your team needs to exercise the greatest level of discipline. You need to drill down on each and every task, and then drill down again. There should be no such thing as a five-day task (this excludes broad category items such as optimization and bug fixing, which can take considerably more than five days). When an engineer, for example, labels a discrete task five days, it's a clear indication that he or she hasn't thought enough about the feature or problem. Break that task down into more specific pieces so that none are longer than five days.

Know What Can and Can't Be Cut

It is also important to have a clear grasp of the essential components of your game and the various components that critically affect the scope of the game. Our companies' founders, Adam Levesque and John Wheeler, among others here, have always impressed me with their fundamental understanding of the required scope of the games they're working on. In other words, they always know what can and can't be added or cut in the game.

Plan for the Unexpected

When building the schedule, account for absolutely everything: attending shows and conferences, creating demos, vacations, sick time, maternity leave, and anything else that could throw a monkey wrench into the works. In addition, we (usually) add a fudge factor - from 15 to 25 percent - for unexpected events. If you truly want to do away with extended crunches, you must live and breathe the notion that you cannot add features or tasks without either removing others or adding time.

Regularly Update Your Schedule

You must continually monitor the progress of your product. Ideally, we update the schedule for all tasks once a week, and we completely redesign the schedule from the ground up half-way through the project in order to apply new thinking, updated information, or just to check that our estimates are holding true. On our most recent project, we didn't always hit the once-a-week update, and we were forced to completely redesign the schedule twice. This was not ideal, but it was better than remaining ignorant.

Use Overtime Sparingly

Having railed against overtime to this point, I'll now add that, when used intelligently, it's actually a very useful tool. It's fairly widely recognized that workers can absorb a temporary 15 to 20 percent increase in their workload for short periods of time. We usually schedule one crunch week for each of the early and middle milestones, and two weeks per milestone during the closing stages. Crunch weeks entail working four 10-hour days. The fifth day (individuals choose which day that is), is a normal day. We publicize crunch weeks well in advance, so people/families can plan for it. Whenever we have to schedule two crunch weeks in the same milestone, we try never to have them back-to-back.

People-Management is Critical

Blame Dilbert: management gets a bad rap in the U.S. Nowhere is this more true than in game companies. Yet managers, the people actually responsible for the direction and performance of the staff, are perhaps the most critical element to your success. Most game companies have people who manage projects, but my observation is that the management of the actual people doing the work is stressed less heavily. It's easy to understand why. Hierarchy, management, and reporting structures aren't necessarily second nature to most game developers. Most game shops were initially formed around the cohesive vision and goal of building a game, and/or on the strength and talent of its founders. Those forces can hold people together to a point, but beyond that point, the company's infrastructure and management provide the glue.

Management is also a sensitive issue. Employees, even the good ones, are human and can falter. Problems outside work can dramatically affect productivity. Employees can lose motivation, become over stressed, lose their focus, or even lose sight of the project's goals. Good managers know how to deal with people effectively. They get the most out of their people and make each of them work better. It is generally accepted in business that a very good manager can improve performance in an individual by at least 10 percent. Conversely, a poor manager costs you at least that, and undoubtedly more. If, in each case, the manager is managing six people (ours manage more) over the life of an 18-month project, this productivity difference is just less than two man-years of development.

Just because a person is your best programmer, artist, or designer, it doesn't mean that he or she is your best manager. And the opposite might be true too. If you make that person a manager, you've done the worst possible thing: taken one of your greatest assets and made him or her far less productive and valuable. On top of that, you've probably negatively affected all the other folks who they are now directing. Egos can be involved when making decisions on who is placed into management positions, but it is up to whoever is in charge to push through that and make the right move.

Lastly, management is also about supervision. The only way that regular work weeks are effective is if everyone is contributing at their highest level during the work day. There can be no sloughing off for a certain number of days or weeks, and then furiously working to catch up. This practice defeats the purpose of establishing regular work hours. Clearly communicate the quid pro quo involved here from the outset. People can have their weekends and regular workdays, but that means we've all got to be working diligently for at least eight hours during the time that we're in the office.

Communicate with your Publishers

Where is the publisher in all this? Clearly, your relationship with the publisher is another one of the key components in keeping schedules normalized. A forward-thinking publisher will understand the relevant issues and won't push the developer to do or promise things that are just not possible under normal circumstances. We've all heard the horror stories, but my own sense is that these destructive developer/publisher situations are becoming less frequent.

Publishers want what we all want: great, non-buggy games shipped on time. In addition, most want to build longer term relationships with good developers. It's up to you to communicate your professionalism and expertise to your publisher. Carefully building a schedule and then being able to adhere to it is one of the best ways to do that. The publisher must believe that the development company knows what it is doing. When this happens, the publisher will more readily trust the studio when it makes recommendations regarding the game, even if that entails cutting features to add others, or adjusting the scope of the game to maintain the schedule.

Against The Wall

Since this article was first written, Blue Fang has wrapped production on Zoo Tycoon 2. During the nearly two-year development of this game, the methodologies and core beliefs described here were tested to the limit, particularly in the final stages. In the last two-month stretch, we endured more overtime than ever before. I'm not proud to admit that faced with the very real concern that we would not hit our targeted ship date, we worked 26 days straight in August 2004 to meet our deadlines.

With our focus on project planning/monitoring, it is logical to ask how we found ourselves in this position to begin with. We are currently dedicating a great deal of attention to fully answering this question ourselves through an in-depth postmortem process. The obvious excuses are there: we were dealing with brand new technology and the scope of the game was much larger and more complex than any of its predecessors. Ultimately, however, we in management have taken responsibility - and rightfully so - and will work to improve our performance so that we don't put our employees in this situation again.

The one positive to come out of this (other than a quality finished product of which we're proud) was a further substantiation that having reasonable work hours makes sense for effective game development. Thankfully, we had well managed our team's time up until that final stretch, and they weren't burnt out going into the final month. Thus, they had enough in reserves at the end of the project to work reasonably effectively during that period. I say reasonably effectively, because I observed the aforementioned costs of overtime (increased error rates, lower overall productivity) during the final weeks, and I'm more convinced than ever that we never want to be in that position again.

In the end, the product shipped in time for the holidays. It was close - closer than we like or are comfortable with - but we got there. We are also doing our best to thank our employees for their efforts. Flowers were sent to spouses every time an employee had to work a weekend (that was very much appreciated-at least the first time) and we diligently tracked each employee's weekend overtime and will be providing them with additional vacation days based on that. Via our postmortem, we will identify areas that need improvement, fix what went wrong, and keep making high quality games that ship on time while continuing to respect our employees' quality of life.

Gone Gold

One could easily write a book on this and related topics. In fact, many have already been written. I strongly urge you to read as many of the good ones as possible (see References). There's also much good work being done by the IGDA on this very subject. If you haven't read the "Quality of Life" white paper the IGDA published in April of 2004, I heartily recommend that you do.

I exhort everyone in our industry to consider new ideas and perspectives on this subject. Don't just accept the status quo, nor the notion that gamemaking is done a particular way because that's the way you've always done it. The truth of the matter is that if you don't recognize the inherent problems caused by extended overtime and death marches, you will be at a competitive disadvantage to the game companies out there who have recognized this and are doing something about it. Companies that effectively manage their time will develop better products and will have a higher likelihood of shipping on time. In doing so, they will demonstrate their proficiency and professionalism to publishers and other partners. Their people will always be fresh, and they will continue to produce high-quality products indefinitely. They will retain their best people and there is a good chance they will absorb the talent from the companies who aren't taking advantage of this improved outlook and work methodology.

If you do things right, you'll hit your schedule regularly, and instead of being working at midnight on a Saturday, you can be home with your family or friends. Heck, you may even have time to sit down and play your favorite game. Doesn't that sound like fun?

References

DeMarco, Tom. Controlling Software Projects: Management, Measurement, and Estimates. New York: Yourdon Press, 1982.

DeMarco, Tom. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. New York: Broadway Books, 2001.

DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams, 2nd edition. New York: Dorset House Publishing, Co., 1999.

Jones, Capers. Assessment and Control of Software Risks. Chairman of Software Productivity Research Inc. Upper Saddle, N.J.: Yourdon Press/Prentice Hall, 1994.

Leipzig, Jeremy. "Work Issues in Software Engineering." N.C. State University, December 2002.

Maguire, Steve. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams. Redmond, Wash.: Microsoft Press, 1994.

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Redmond, Wash.: Microsoft Press, 1996.

Metzger, Phil and John Boddie. Managing a Programming Project: Processes and People, 3rd edition. Upper Saddle River, NJ: Prentice Hall, 1995.

Rothman, Johanna. "Taking the Crunch Out of Crunch Time." Software Development Magazine, March 2000.

______________________________________________________