Live data from Hacker News

This Dumb Industry: In Defense of Crunch

shamusyoung.com

51–60 of 60 posts

Re: This Dumb Industry: In Defense of Crunch

#51
post #43
post #17

Earlier quoted context omitted.

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.

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 (…

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

Re: This Dumb Industry: In Defense of Crunch

#52

Earlier quoted context omitted.

> 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 t…

> 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.

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.

Re: This Dumb Industry: In Defense of Crunch

#53
post #22

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…

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…

The metric for success on any commercial software is long-term ROI, not "fun" or "functionality". This applies to both games and business software. Fun and functionality can't really be quantified in a way that's consistent or comparable across products.

Some of the most successful games aren't really much fun for the most active players, such as MMORGs and free-to-play mobile games. They seem to succeed more through triggering addiction and a sense of competition amongst players rather than providing an enjoyable experience.

Re: This Dumb Industry: In Defense of Crunch

#54
post #6

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.

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 cr…

The US Navy developed evaluation and review technique specifically to solve the first problem. For a particular task you can say: optimistic time = 1 week, most likely time = 2 weeks, pessimistic time = 20 weeks. If you decompose a large project into a large number of smaller tasks then the critical path schedule estimate should be close to reality. Or if you want to be more sophisticated you can do a Monte Carlo analysis to create a probability distribution of possible completion dates, and then make commitments based on whatever statistical level of confidence makes you comfortable.

Re: This Dumb Industry: In Defense of Crunch

#55

Earlier quoted context omitted.

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…

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.

The point of agile is for a team to achieve the maximum possible sustainable velocity. If you're building a custom line-of-business application, a web SaaS, or shrink-wrapped productivity software then you typically want to manage it as an ongoing program with multiple releases spread over many years. So a rational manager won't burn the team out on the current release because she needs to keep the team intact to work on the next release. Whereas with most games there's very little maintenance and enhancement work after the initial release, so it might be economically rational to overwork the team in the short term even if that pace is unsustainable.

Re: This Dumb Industry: In Defense of Crunch

#56
post #24

Earlier quoted context omitted.

> The thing with voluntary crunch is it becomes institutionalized and part of your company culture. That's exactly what the author argues teams must avoid. His premise is explicitly that a little crunch isn't harmful as long as it's not an institutionalized part of the company culture.

A little crunch is harmful too, just less harmful. Crunch is rarely a necessity. If the deadline can't be moved, and you're going to miss it, work on cutting the workload (drop features, etc...). If the project can't have any corners cut, then move the deadline. If neither of these is an option, then do what you have to do and find new managers for the next project, because they should've been more on the ball and pl…

I don't think the author would disagree. He's saying that if you avoid crunch 99% of the time then crunching for the last 1% isn't very bad and might even be good. He's not saying you can avoid 99% but the last 1% is inevitable.

Re: This Dumb Industry: In Defense of Crunch

#57
post #56

Earlier quoted context omitted.

A little crunch is harmful too, just less harmful. Crunch is rarely a necessity. If the deadline can't be moved, and you're going to miss it, work on cutting the workload (drop features, etc...). If the project can't have any corners cut, then move the deadline. If neither of these is an option, then do what you have to do and find new managers for the next project, because they should've been more on the ball and pl…

I don't think the author would disagree. He's saying that if you avoid crunch 99% of the time then crunching for the last 1% isn't very bad and might even be good. He's not saying you can avoid 99% but the last 1% is inevitable.

> "the last 1% is inevitable"

I don't think it's inevitable at all. If you plan for slippage by not being too optimistic with time schedules then it can be avoided.

Re: This Dumb Industry: In Defense of Crunch

#58
post #51
post #43

Earlier quoted context omitted.

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 (…

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

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.

Re: This Dumb Industry: In Defense of Crunch

#59
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.

Re: This Dumb Industry: In Defense of Crunch

#60
post #56

Earlier quoted context omitted.

I don't think the author would disagree. He's saying that if you avoid crunch 99% of the time then crunching for the last 1% isn't very bad and might even be good. He's not saying you can avoid 99% but the last 1% is inevitable.

> "the last 1% is inevitable" I don't think it's inevitable at all. If you plan for slippage by not being too optimistic with time schedules then it can be avoided.

> I don't think it's inevitable at all.

I said the author is not saying it's inevitable.

Post reply on HN