
This Dumb Industry: In Defense of Crunch - suraj
http://www.shamusyoung.com/twentysidedtale/?p=31667
======
patio11
When people who work in the games industry say they crunch because they're
young men with poor boundaries who would do anything to make video games, and
when industry veterans literally write PowerPoint decks about hiring
suggesting targeting young men with poor boundaries because you can get them
to crunch since they will do anything to write video games, I choose to
believe their words. This lines up with external evidence.

Scheduling software is hard: granted! But do we see 90 hour crunch on _every
single shipping product_ in the US software industry? No, that's ludicrous. Do
we see 90 hour crunch on substantially every shipping software project in, I
don't know, the Japanese software industry? Oh we do! Curious! Does that
industry also write schedules which assume crunch? I mean it sounds far
fetched but no, literally in the design document written in the _first week of
a three year project_ there are exhortations about how understaffed we are
(Why?) and how tight he schedule is (Why?) and how required heroic efforts are
(Why?). And does the Japanese software industry hire people with poor boundary
control and ruthlessly inculcate lower boundaries? Great Scott it does!

Crunch in the video game industry is not an accident. It is a policy. Do not
work in video games.

~~~
hacker_9
I think you might be missing the point of the article. The metric for
measuring a game's success is how fun it is to play. You can't plan fun, that
only comes from having a playground and tweaking things until the game play
feels satisfying. Note I use words like _fun_ and _satisfying_ \- words that
are all highly subjective, and can only really be ticked off when you have the
game in front of you and can agree it was fun to play.

The metric for measuring the success of software on the other hand is directly
proportional to the amount of functionality it implements, as defined in the
requirement spec. These totally different goals for development are the reason
the industries are so different, and why one is harder to plan for than the
other.

~~~
andrewvc
A major point of the agile manifesto was that building any software to a
waterfall spec results in unhappy users. Even enterprise software is
iteratively designed these days (well at good places at least). Games are not
special.

~~~
hacker_9
Agile is no magic bullet. Additionally 'change' means a very different thing
when you are talking about in-flexible data (3d models, textures, animation
etc), and usually means throwing the data away completely and starting over.
This is a lot more work that adding a form field to a web page, or changing
the business logic behind a query by moving some code around.

~~~
bartread
This^^^. Scheduling for some types of software is harder than others. I mean
it's always a pain in the neck, but not necessarily intractable.

I used to work on shrinkwrapped tools for SQL Server and .NET developers, and
over time got pretty good at scheduling releases with an ever narrowing window
(that was never that wide to begin with), even accounting for the inevitable
changes you'd need to make as you got customers to try out the software
throughout the project. And you needed some degree of certainty over
scheduling in order to coordinate with marketing, make sure sales and product
support were trained, dovetail with other projects so that people could be
reassigned, etc. Key point, as well: teams are cross-functional, but
relatively small.

Line of business apps are trickier because you're often dealing with
stakeholders who either aren't sure, or can't well express, what they need.
You also have the kind of integration problems that occur much less often than
with shrinkwrapped software. Cynically, I feel like a lot of unwillingness to
schedule for these kinds of projects - especially for moderate team
size/complexity - is really because people just don't like doing it, for a
variety of reasons. And by schedule, I mean sit down and do the homework as it
were in detail, not just throw a convenient date up on the board (I've never
seen anyone do a good job of estimating a software project in the large this
way, and it doesn't help the business make informed decisions when you end up
shifting the date or cutting functionality under duress later on).

You get similar problems with public facing web apps: because you can roll out
a new version of the software whenever you want this allows you to chop and
change functionality as needed (or wanted), so things can grow tentacles. Team
size and complexity can vary a lot here but, obviously, bigger, more complex
teams make it harder to schedule. If you're rolling out functionality
incrementally though, this may not present a big issue commercially.

Games are a whole other thing, because the feel of playing, and the fun factor
are absolutely key. This is also why I don't think film development is a great
analogue for game development. Film is _not_ interactive, but games are, which
adds a layer of complexity film doesn't need to worry about. And this comes
whilst having a production team of a comparable size and complexity to that of
a film for big budget games.

To be honest though, I'm not sure how much team size and complexity factors in
with games - just watch the Indiegame film where you have very small teams in
all cases, yet (particularly memorable with Fez) development takes massively
longer than expected, and involves a rewrite to get the game right. If that
hadn't happened it wouldn't have been as good a game.

Like I say, I think games really are a different kind of problem - perhaps the
closest thing software project management has to an NP-hard problem. It's
really no surprise they ship late, and that crunch is a reality. Perma-crunch
though: well, that just makes me feel sick to think about.

------
Animats
If game development paid overtime, game scheduling would be as well developed
as film scheduling is. When a film goes over budget, the director and producer
usually get their share cut.

I've written about this before. [1]

[1]
[https://news.ycombinator.com/item?id=9557954](https://news.ycombinator.com/item?id=9557954)

~~~
maxxxxx
Paying overtime would solve a lot of project management issues in tech
companies. Overtime is for free so why try to avoid it? If people get burnt
out after a while there are plenty of people who are happy to replace them.

~~~
apercu
I think this is the crux of the problem - in the US and Canada (at least)
there is an IT class of professionals that are exempt from overtime. Why?
Please someone tell me why?

And it's not just the gaming industry.

I am involved with 10 projects right now (way more than my usual load). 1 of
them has a reasonable schedule (though my component is sort of aggressively
scheduled), 3 have completely ridiculous schedules (from day one requiring
overtime and weekend work to complete), 1 has stupid political nonsense going
on which makes it a complete cluster __ __that is making the timeline silly, 2
others are being rushed in phases, since the timeline was stupid to begin
with, 2 others are crunched because they are related to the 3 that have stupid
timelines (forcing the team to split in to 5 different teams and work in
parallel) and the last one is being finalized but had some pressures on my
component, which rushed my work.

So, anecdotally, 90% of the projects I am involved in currently have issues
with their scheduling.

As I have been involved with software/hardware development since 1995, my
experience suggests this is nothing new.

~~~
Animats
It's time for repeal of some Fair Labor Standards Act exemptions. There's one
for computer programmers.[1] The threshold for exemption from overtime needs
to be pushed up to the point that only the 1% are exempt.

[1]
[http://www.dol.gov/whd/overtime/fs17e_computer.htm](http://www.dol.gov/whd/overtime/fs17e_computer.htm)

~~~
apercu
I agree 100%. When on salary you are buying a piece of my time in exchange for
an agreed upon amount of compensation. For an employer to make the former
variable but not the latter is B.S.

Also, the whole more than 40 hour per week expectation is nonsense. I am
independent now and can do the same (or more) amount of work in 30-40 hours a
week now. In fact, I worked ~500 fewer hours my first full year of being
independent. Did I make a little less money? Sure, because I don't get paid
time off anymore. And I also worked a lot less.

------
Macsenour
There is nothing that I agree with here. Crunch = Producer fail. Feature Creep
= Producer fail.

The suggestion that "scheduling is hard", no sh*t Sherlock, that's why you
don't hire a 20 year old Producer who did one title at this last company.

------
flashman
"It’s your entire job to say no to stuff like this [asking for more time]."

No, as a manager it's your entire job to make sure stuff like this doesn't
happen. How did you let the project lead get into this situation? How
irresponsible was it to basically gamble - not just with money, but with other
people's time and careers - that the project would be on schedule? "Oh, but
that's the way games get made." Right, so now you're just normalizing
deviance.

------
quanticle
>Scheduling isn’t just a problem in videogames, this is all kinds of software
development.

And yet, somehow, videogames still manage to be worse about scheduling and
effort estimation than pretty much any other kind of software system. Why is
that? Why do managers of video game development teams feel like their industry
is a special snowflake in software, that it's not bound by the same
constraints as enterprise CRUD apps?

EDIT: Literally every point he brings up regarding feature creep and
estimation applies equally to enterprise CRUD apps. So as bad as estimation
for enterprise applications is, I never hear about people working 80-hour
weeks for years on end to bring Widget Planner 3.55 (Now With Fruble Support!)
to fruition.

------
jacques_chester
I see a lot of cases of people saying estimation is impossible, which upon
closer inspection turn out to be a different argument: "perfect foresight is
impossible".

The Nirvana Fallacy, in other words. Because it's not perfect, it's worthless.

Of _course_ perfect estimates are impossible. You need to make them anyhow.
And if you don't make them explicitly, you'll make them implicitly, and
they'll be worse.

~~~
x5n1
That's not the problem. The problem is that each step in the process is
variable, and it's not variable by a small amount but potentially up to a
magnitude. That's the problem. The second problem is that the industry does
not pay for reasonable estimates, they want imperfect unreasonable estimates
which are very conservative with which to beat the employee or the contractor
over the head with to force overtime and crunch.

~~~
jacques_chester
> _The problem is that each step in the process is variable, and it 's not
> variable by a small amount but potentially up to a magnitude. That's the
> problem._

That's not unique to game development. Or software. Or any industry, really.

> _The second problem is that the industry does not pay for reasonable
> estimates, they want imperfect unreasonable estimates which are very
> conservative with which to beat the employee or the contractor over the head
> with to force overtime and crunch._

Of course, but that's because the estimate is not being treated as an
_estimate_. It's being treated as a plan, or a goal.

I read a book called _Industrial Megaprojects_ in which the author, talking
about civil and industrial projects on a gigabuck scale, lamented the same
problems.

~~~
marcosdumay
> That's not unique to game development. Or software. Or any industry, really.

Yes, it is. It's not literally _unique_ to software, because R&D and "nobody
ever made something like this" projects share it, but most industries don't.

~~~
Macsenour
In games we HAVE to push things forward, we HAVE to innovate or seen as a copy
of an existing product. That being said, that's what "Pre-Production" is all
about, answering the questions that are new to this project.

In the piece it says something about "needing more windows", that isn't what
I'm talking about. That's just poor game design at the outset.

I was refused an interview once because they were looking for the exact person
who had done a hit title, he "obviously knows what he's doing". The product in
question was 2 years late and 1.4 million over budget. I said: "I can do
that...". I think the game industry is unique in that we're often hired, or
not hired, based on how famous the title was that we worked on last.

------
HillaryBriss
> Keep in mind that when you’re giving a quote like this, you are basically
> making a promise to get the job done for a certain price.

Favorite quotation from this article. So much insanity and stress flow from
this.

But hey, this is a team. We're all in it together. If things go wrong, count
on my support ... unless it means you'll miss your deadline. What kind of
loser-idiot misses their deadline? I asked you how long it would take at the
start! Why didn't you tell me six months ago it would take three additional
weeks? Let's try this again: how long will it take to finish level 9? I think
you know the right answer now, don't you?

------
georgemcbay
All those words and none of them touch upon the obvious financial bullshittery
of being expected to work as much as double time for the same salary.

~~~
apercu
When I started my career I worked for a University and then a private
scientific engineering/manufacturing company. The latter was purchased by a
public company. They cut 20% of the staff and expected the same output. This
has been going on for 20 years.

------
rock_hard
"scheduling is hard"?? Yeah, if you have no fucking clue what you are doing I
guess everything is hard!

Shipping successful products on time and in-budget is not rocket science! The
right people are out there...you just have to hire for it.

~~~
apercu
It is not hard at all, but typically external pressures force people to agree
to things that don't make sense. I have a client that has an event every year
at the same time (let's say it's mid-July. They want projects to be completed
before this event every year. But for some reason, they don't start planning
these projects until let's say end of April. So every year it's the same crazy
pressure and quality issues.

If only the planning for these projects started in say, October? But no, in
October the team is still dealing with the fallout of the poorly planned
projects of the current year.

------
partycoder
You can take risks, but you must have a share of the rewards. Taking risks in
exchange for nothing is not fair.

------
megablast
Seems like the solution to this is not to promise release dates, and fixed
budgets.

~~~
taurath
Release dates aren't going anywhere as long as there's a traditional retail
chain and marketing spends.

You can do a hell of a lot to just pay workers overtime - people in the film
industry in LA may work overtime, but if they go overbudget it comes out of
the show runners cut. In software overtime is just free time, and they'll
squeeze you out like an orange and replace you with a new fresh eyed person
when you can't go anymore.

~~~
pjmlp
> In software overtime is just free time, and they'll squeeze you out like an
> orange and replace you with a new fresh eyed person when you can't go
> anymore.

Thankfully, in many European countries software development is under the same
rules as any other job, and one is entitled to get either free time or money
form those extra hours.

Granted not all companies play ball, but then one can make them play ball, if
they feel like getting some external help from either unions (we have IT
unions) or lawyers.

~~~
pjc50
The "management" exemption is often heavily abused to extend unpaid overtime.
It happens at e.g. Rockstar and Jagex.

------
wglb
When I was younger, I decided that failures in schedules were failures in
management. Now that I am older, I feel that failures in schedules are
failures in management. Not failures in technology.

As patio11 mentions elsewhere in this thread, schedule crunch, except for the
very first time, is a deliberate decision.

------
supercoder
I'd never work for this guy

------
vvanders
Nope, nope, fuck you.

Voluntary crunch leads to a culture of overtime. You won't be considered a
"team player" if you decide that you don't want to spend weekends and extra
hours in an industry where you make 40% less than your peers.

I feel even stronger about this after having a kid. There's no way I'm
destroying the relationship I have with my family for your product. I saw it
again and again when I was in the industry(at least 3 divorces on the last
project I worked on) and I'll never go back.

~~~
FussyZeus
I agree, and as a consumer of games I find crunch stupid and unnecessary. If a
game needs another week just DELAY IT A WEEK. This idea that once marketing
sets a date of completion that it's a total must-make is complete nonsense.

~~~
ludamad
Except it isn't. An entire company could be jeopardized for missing eg a
holiday deadline.

~~~
FussyZeus
That's quite possibly true now, though I'd argue that is largely because game
publishers killed the goose that laid the golden egg by shipping tons of
totally broken games and ruining the idea of pre-ordering. Likewise I think
that process could be reversed by showing fans that the company brass actually
gives a damn about their product enough to delay it when it needs more time.

Nintendo is a fantastic example of this, I would say this happens to a good
chunk of their titles, Zelda especially. Yes it's always a bummer, but
Nintendo also hasn't had an Arkham City or a Division where the game comes out
half finished, full of bugs, with the promise of "we'll patch it later."

