česky english


News & Announcements

Developers' diary


June 2014

May 2014

April 2014

December 2013

November 2013

September 2013

July 2013

June 2013

December 2012

October 2012

August 2012

June 2012

May 2012

March 2012

February 2012

January 2012

July 2011



Filed in Developers' diary by Martin @ 8:46 am UTC Aug 30, 2012

Niko Vuori, General Manager at Zynga

The most depressing thing about the recent kerfuffle about Zynga’s disgruntled workers were not the comments of Niko Vuori, Zynga General Manager, who assured the sheep in his flock that "NO ONE IS FORCING ANYONE TO WORK HERE AGAINST THEIR WILL [sic]", but the reactions of other developers to the effect of "be a man, dude, game development is not for wimps", followed by the yarns of the saintly days of yore when we all slept under our desks, ate cold pizza and ain't seen the sunshine since I don't know when.

Now, for the record, I have to say that criticizing your current employer is a dumb thing to do, because it makes you look like a sap. If you are so smart and they are so stupid, why are they employing you and not the other way round? To this limited extent I agree with the comments of Mr. Vuori.

However what I was again surprised by was the widespread feeling that game development has to be solitary, poor, nasty, brutish, and never short enough. Long term relationships are incompatible with the life of game developer. Overtime is a fact of life. As one developer put it, "…if you do not give the game everything you have, how can you expect anybody to give a damn about it?"

During my time I developed a complex relationship to the word "passion" – as in "required: passion for videogames" or "we look to reward people who are passionate about their work". More often than not it is a code for "sucker": a person who is willing to cover the ineptitude of their managers by working longer and harder "for the common good".

Am I then against passion? Would I prefer indifference? Do I want to work with people who are lukewarm about games? Do I want people not to care about the game they are making? People who punch in at 9, punch out at 5, I’m-all-right-Jack, works-as-designed-so-not-my-problem kind of people?

Of course not. But I do hate it when managers abuse and exploit this noble sentiment to make up for their shortcomings. Because make no mistake, the root of all evil in game development is the poor scheduling and this is the responsibility of management, the producers, people who are least likely to suffer when it goes wrong.

In this blog, I would like to outline what I think is wrong in game development in general and how we want to challenge that in our studio. I am afraid that to some it would sound like blasphemy, but this is the way I see it.


Game development is based on lying. The developers lie to producers about the completeness of their work. The producers lie to the head of the studio about the state of the project. The studio lies to the publisher about deadlines and features of the game. The publisher lies to the gamers about everything.

Part of the lying is improbable deadlines and pointless crunch. Everybody knows – there are studies to prove it and it is quite obvious to anybody who experienced it – that long-term crunch does not increase productivity. By working 80 hours week, you may be able to do twice as much for a while, but probably for no longer than a month. And then you will need another month to recuperate, so averaged over the whole period, the amount of productive work is likely to be the same.

Tim Lister and Tom DeMarco, authors of Peopleware

This is especially true of the highly intensive and non-trivial work like programming. DeMarco and Lister say that top-notch companies can extract six hours of productive work from a programmer per day, while an average would be about four hours. This is based on a normal, eight hour day. Now, to think that forcing a programmer to sit at his desk for an extra four hours will extract three more productive hours of work from him, is to have no experience of programming.

"I love the sound of deadlines whizzing by," the Lead Programmer of one of the companies I once worked with used to say. Every developer will tell you stories about working to a deadline everybody knew was ridiculous and yet management persisted in denial. A typical example from my own experience goes like this:

Project Manager Bob, speaking at a progress meeting in September: “My Microsoft Project chart shows, that, assuming no new task will appear, the work will be finished by Easter.”

“Thank you, Bob,” replied the Producer. “Now, let’s talk about our release this Christmas.”

This game was actually published at Christmas, two years later.

Phony deadlines are the most corrosive solvent of the team morale. No amount of free food and team-building can repair the damage done by the team missing a deadline again and again, of wasting months and months of work on features that had to be cut eventually.

This is the result of the mindset that wants to have their cake and eat it. We want to ship by Christmas and we want to have everything we designed and more. Every project manager will draw you the Time/Cost/Scope triangle but few seem to be able to believe it. Rather, they believe that in their special case, an exception will be made; if you hope fervently enough, if you truly believe in something, it surely must happen. That’s called positive thinking, isn’t it? And if it didn’t work, we hadn’t believed strongly enough, so we have try harder next time.

The typical situation is then like this: there is a phony deadline everybody knows the team is going to miss. There is a crunch that everybody knows is not helping to finish the game any sooner. It’s then difficult not to see overtime and crunching purely as a ritual, a kind of punishment or atonement. Crunch is management using the work of the rest of the team to make penance for screwing up the plan.


In Warhorse, we wanted to create a game studio for adults. We do not give baubles to the "employee of the week". We do not do team building exercises. We do not give free coffee. We prefer to give cash.

The core of our approach is that we respect the individuals that make up the team. We do not make claim on their personal life. We do not want to make the pretense of being one big happy family, indeed, most people on the team have their own happy families and we would much rather they spend their free time with them then with us.

This is of course also just making virtue of necessity. We are a startup, we are on a very tight budget, we could not fly the team to the Savoy Alps for a weekend of teambuilding even if we wanted to. We could just about afford the free coffee.

But even if (or when) the situation changes, I would still much prefer to spend the money by giving it to the people who earned it for the company to use as they see fit, rather than forcing them to spend another weekend in each other's company and mine.

Part of treating people like adults is assuming that they can handle truth. We do not want any feel-good white lies at Warhorse. If there is a problem, we want to know about it as soon as it appears. If we can't solve it, resulting in a feature cut or deadline moved, then so be it. No amount of denial is going to change this simple fact – the feature will have to be cut or the deadline moved and living in denial will only make you spend more unproductive work on it.

Another cliché beloved of project managers is “aggressively closure-minded” and though it sounds awful, it actually helps. Your focus must be the project – the game – as a whole, not any single feature.


We have just passed our one year anniversary at Warhorse and I felt that we should hold some kind of review, not only of our progress – this we review somewhat more often than once a year – but our process, the procedures we use, the people that make up the team.

Joel Spolsky, of Joel-on-Software

For bigger companies the Performance Review is par for the course. I experienced it myself several times, in a traditional I-and-my-boss form, and while not really stressful, the most pervasive feeling was one of utter pointlessness. I was thinking about asking the people on the team to rate or grade other people on the same team (programmers, artists, etc.), but then I read this interesting blog by Joel Spolsky, arguing convincingly against any form of performance review.

My current thinking is that it would be consistent with the thesis outlined above – management is most often the point of failure in a video game’s development – to review only managers. So we would ask the developers to anonymously rate their managers and leads, as well as the process that we are using.

I would however welcome any feedback on this point: what is your experience of Performance/Team Review? How does it work in your company and are you satisfied with it?

Martin Klima, Executive Producer

blog comments powered by Disqus