Does Epic know that Project managment tasks are scheduled by hours of effort, not just fixed time intervals?
So, my guess is that for each hour you work over 8 per day, you are getting, what 20 percent less productivity and this starts dropping really fast... (I know that there are good arguments against even 8 hour days).
One of the rare, sensible articles I saw out of some (casual) studio in the UK was that they addressed an awful lot of productivity by taking most people's desktop Internet access away. I've certainly seen this as well.
It is always good to see that the games industry is at least 30 (40?) years behind the rest of the IT industry in its development maturity.
Predictability is what you want to strive for most of all.
Steven B. Davis
IT GlobalSecure Inc.
Technology & Business Development Mail:
IT GlobalSecure Inc.
808 Comet Drive Suite 205
Foster City, CA 94404
Corporate & Official Mail:
IT GlobalSecure Inc.
114 Hobbs Street
Greensboro, MD 21639
To no longer receive email from Steven Davis & IT GlobalSecure Inc., please respond to this email: c...@secureplay.com
In "new-economic/business-model distributed teams" people are likely engaged in piece work (excuse me, milestone based payments), so their hours are not an issue. This is clearly for on-site employees.
>> I'd like to see some links on the productivity drop by hour.
Me too. It is certainly intuitively true (just as there is some minimum amount of time to get to the point of getting anything done).
>> Doesn't work for other departments, to much lost productivity getting IT
>> to unblock a site because you need it to find background info or
>> references, both for code and art.
For a studio / office, I tend to recommend a separate set of machines that have Internet access (full, unfettered). This makes it physically clear when someone is "on the Internet" - whether for work or play.
(your mileage may vary)
>> I could perhaps see it to block certain sites like email sites and forums
>> during work hours, maybe even flash to stop people playing games when they
>> shouldn't, but that'll depend on what kind of games your making, less
>> beneficial for casual makers etc.
>> There is always a balance though.
Many think that crunch is just an evil that needs to be removed by
I don't think it is that simple. Here is my theory:
Anything that is possible to do, will be done on budget and schedule
+/- 10% disregarding of its schedule and budget.
7 years after 9/11 ground zero is still just a hole. The empire state
building was built under schedule and budget, in less then a year. We
have better technology, better materials, so don't tell me it is more
complicated now then in 1934. (BTW, Empire wasn't badly built, it
withstood a plane crashing in to it...). The U2 plane was built in
less then a year too, today a military plane takes 20 years to develop
and they still cant make anything better then a Hercules.
The only way to get the impossible, is to ask for it.
If you say "making this game is going to cost 30million and take 3
years" Guess what, people will crunch the last weeks. Extend that by a
year and you will just delay the crunch a year.
Games cost a lot of money and takes a lot of time to make because we
want them to.
The fact is that people crunch because they want to get more stuff in
to the game.
At GDC this year I went to a talk about Red Faction. They talked how
incredibly hard it was to build destructible environments. But if you
work hard enough on it you can do it in this generation. All i could
think was: Super Marion Bros. It was possible to do in the 80s, it was
even easy to do in the 80s, it will probably be even harder to do in
the next generation. We create these arbitrary rules for what a modern
game has to be. Things that make game development hard and expensive.
Rules like "Everything has to be bump mapped". When you corner your
developer with less money and time, you force them to innovate.
Also if i look back at my time in crunch its the time i remember the
best. No team building works as well as crunch (Often though the team
bands together against management...)
Do i think that crunch makes games better? No, but i think releasing
games do, and any reasonable deadline will produce some amount of
Large game projects today are frequently run by under-qualified staff.
I have been more and more amazed year on year how few really good
people are in studio-level exec positions, and how many has-beens and
failures are instead.
And then there's Scrum, which neatly sidesteps your core argument:
there will be no crunch if there is no arbitrary deadline. What
benefit is the deadline, anyway?
I have a friend who used to manage strike teams for McKinsey, and
admitted a fondness to telling teams about their deadlines a mere
couple of days in advance. He called it "managing by artificial
emergency" IIRC and felt his talented arrogant teams were too lazy for
their own good and needed this kick up the ass to make their best
work. Huh. That's in an industry (consulting) where the deadlines are
a lot more real than they are in ours.
But, again, with Scrum, since you can ship any week you choose, with
zero advance warning, the external stakeholders who require a
particular, arbitrary, ship date can have that whilst not screwing up
the dev team.
Scrum done well is a perfect fit for most game developers, IMHO. And,
IMHO again, that's why it's been sweeping through our industry so
rapidly and somewhat rabidly :).
I think crunch is worthless and nearly always caused by idiotic
managers who were never taught how to prjoect manage properly (it's
amazing how many so-called trained PRINCE2 practitioners declaim that
it's overly rigid; how the heck did these people qualify? Or did they
lie on their resumes? Hmm).
Crunch is where you steal free unpaid overtime from your staff. Yes,
it is stealing, because it's a breach of the employment contract where
you contract a certain amount of work for a certain amount of money.
Plain and simple theft.
Paid crunch is a very different matter. Funny how all the
institutional (*) active users / proponents of crunch never seem to
offer to pay overtime for it, isn't it? When they start paying for it,
I will start being open to the belief that crunch has some value in
making a game. Until then, Occam's Razor suggests the real
purpose/benefit is to reduce the expenditure on salaries.
(*) by which I mean the companies that deliberately rely on it, not
the people who are moderately defending it, like Bruce and Eskil
> At GDC this year I went to a talk about Red Faction. They talked how
> incredibly hard it was to build destructible environments. But if you
> work hard enough on it you can do it in this generation. All i could
> think was: Super Marion Bros. It was possible to do in the 80s, it was
> even easy to do in the 80s, it will probably be even harder to do in
> the next generation. We create these arbitrary rules for what a modern
> game has to be. Things that make game development hard and expensive.
> Rules like "Everything has to be bump mapped". When you corner your
> developer with less money and time, you force them to innovate.
You see, Eskil, I think you secretly are wholly anti-crunch :), but
that other - positive - things have got aggregated into the term
"crunch" by people trying to create defences for their own terrible
practices, adn it's just that you see some good from some of those. I
believe you can get all those benefits better, at less cost, without
using crunch, but instead using other bits and pieces of methology to
You just gave a great example that suggests that crunch is the wrong
approach; more intelligent design and more intelligent project
management would be far more effective.
Do you know what you call a game developer who doesn't produce anything?
Nod. Again, a core tenet of Scrum :P. IME, that's one of the few parts
of Scrum that people actually remember to do.
> Do you know what you call a game developer who doesn't produce anything?
> A producer.
The first 3rd party dev studio I worked with when I joined a publisher
was using Scrum, and saying exactly that.
The problem was that they were producing crap every single milestone,
and their sprints were achieving nothing.
At the time, the publisher didn't understand Scrum either, so wasn't
sure what to do. With hindsight, having had a lot more experience of
Scrum, I believe it would have been obvious for all concerned: judge
the team on the results, not the excuses.
(in fact at the time we did judge them, and hard, on the lack of
progress, and refused to accept this hand-waving about "we're using
this new thing called scrum" as an excuse for their poor builds. But
that was based on common sense and a feeling of "WTF is going on here?
how come their builds are so terrible? and not even slightly fun?")
So. convince an outside stakeholder/client/investor that this is
exactly what will happen - that they will have very early visiblity at
all times, and that they have only to object at any time - and I think
you'll have them on your side. You'd need suitable restitution
clauses, of course...
> WoW had an outside publisher and look what happened at launch? They wanted
> to hit the deadline so much (as is the fault of nearly ALL MMOs released
> nowadays) that they sacrificed bits here and there, even scrapping entire
> ideas just to get it out. It sucked at launch. There was no stability.
As has been said quite a few times, stability of an MMO has never
truly been a major commercial issue, except in the minds and dreams of
developers, and in extreme cases of instability at precisely the wrong
moment (AO refusing to accept credit-card orders being one of
those...but the point was it was more important "how easy is it to
spend money?" had gone wrong rather than "a server has gone down").
> initiative and SHOW the big companies how it can
> be done.
That's the spirit!
My feeling is that the way to do it is not to remove crunch, but to
remove "release". I release to my alpha group every two weeks or so. I
never feel that a release is the one i have to get everything in to,
so no crunch. Then again i already work 7 days a week...
> HR and the boss...don't forget them :D
HR: How the hell do you judge a programmer without being one? I'm a
programmer and I still think its hard.
Boss: How do you get respect and the knowledge you need about what you
do to be a boss without diving in and working on the project?
Sorry, EVERYONE who makes a decision needs to work on the projects. I
can imagine hiring someone unqualified to answer the phones, fill the
coke machine, arrange plane tickets and look good in the lobby, but