Also as an American currently living in Canada, I must disagree. Canadian healthcare is FAR superior.
Canadian healthcare does the job -- everyone has a basic level of care. For specialized services that are not life threatening, you wait. In the US, if you are fortunate enough to have good insurance, you can fight your way through the system and get care...once. After that, you're hosed unless you manage to keep insurance through your work, because you'll never get insurance personally again.
My wife waited 3 months for a gynecological procedure in Bellingham, WA before we moved. She's been waiting for 5 months or more here in Vancouver for a possible knee procedure.
Emergency medicine is exactly the same here except that you don't get a multithousand dollar bill at the end of the experience.
Our last complete year in the US, we paid over $14,000 US for medical insurance. In BC, we pay about $1300 CDN. The $5K CDN or so in extra taxes we paid saved us a bunch of money.
And BTW, only 2% or so of Canadians ever avail themselves of US healthcare, despite claims that Canadians flock to the US to get care they can't get on time in Canada. Just ain't so.
Over more than 20 years as an independent developer (mostly in games), technical director at EA, manager in game software development, and manager in non-game software development (core technology), I've managed to plan, estimate, schedule, and deliver software on time without resorting to long-term crunch. Not only did I write the Crunch Mode paper we're discussing, I've been speaking (at GDC and elsewhere) and writing on the general subject of improving development practices for well over 12 years -- since the early 90s, in fact.
In my experience, proper line and project management can correct for failures of initial planning, requirement creep, and even poor scheduling. Of course there are limits: one can't deliver a full-fledged AAA game console product in a couple of weeks just because it's well managed. Of course there are challenges: game development is harder to predict because the elusive "fun" quality is even harder to design than the "useful" or "elegant" qualities that must be in other, non-game, software.
But one common practice that I've encountered which proper line and project management cannot correct for is cultural reliance upon crunch mode. Poor planning can be overcome: willful or ignorant mismanagement on the ground cannot.
Computer and console game software develoment goes back well over 20 years.(I know. I was there.) In the beginning, pretty much everything we did was ad-hoc. Now a lot of it is decently estimated and scheduled, but a lot of it is still not well-managed.
Crunch mode is a symptom of that management failure, not a result of any inherent intractibility of game projects. I've made a career of delivering projects (most of them games) with minimal slip and almost no crunch mode. It can be done.
Actually, it's a coding manager's attempt to rationalize insane behavior:-).
I don't believe that management is happy that crunch mode happens. I do think they want to maximize output, but that's kind of an assumed desire, because what they really want is to produce product that makes a lot of money. Making product that sells well is one branch of that ultimate desire, and reducing the costs of product is another. I don't think management sits around constantly asking "how do we maximize the output of our workers". But maybe they should:-).
I think the major disconnect is the idea that hours in seats is a good proxy measurement for total useful output. This idea is the basis for the decision to use crunch mode (although I'm pretty sure it's rarely expressly stated). It's an idea that's widely discounted by experienced workers and managers (even those who use crunch mode routinely) and the studies agree that it should be discounted. You can say that crunch isn't the problem -- that there are a whole host of reasons why crunch happens -- but the crunch mode technique is, in and of itself, a problem because it actually delivers the opposite of what is wanted when it's used -- more output.
So poor planning is a contributor, but it's not the essential problem. The essential problem is failure to understand that the result of long-term crunch mode is lower total output.
Obviously one can program 80 hours a week. The question is whether you should.
There are clearly two sides to the question: is it good for the programmer to program more hours? and is it good for the project for programmers to program more hours? It's not necessary to pretend that these are the same question: there are exceptionally important projects with close deadlines (see Marc Stiegler's David's Sling for a fictional example) where the end result is so important that destroying programmers is acceptable collateral damage so long as the project is completed within a very tight time frame.
So: is it good for the programmer to program more hours in a week?
On average, no. Sure there are some programmers who can maintain an 80 hour week indefinitely, but the modal programmer will suffer loss of productivity as well as undesirable physical and mental side effects after some period of extended additional work.
Studies as far back as the first decade of the 20th century have demonstrated lessened productivity and increased accident rates with 10 hour work days compared with 8 hour work days. Modern studies of stress and sleep deprivation show that losing as little as an hour of sleep a night can have an effect similar to taking one or two stiff drinks.
Personal experience suggests that there is an average threshold after which effects become more severe -- somewhere between two and four weeks of 50+ hours. That doesn't mean there are no effects earlier, it's just that the effects become more obvious with time and hours.
How about the project? Is it beneficial to the project to work more hours?
In some limited cases, yes. As productivity (output per unit time) decreases, increased work time can result in an actual increase in productive output. So if you really need to have something done next week, you can get extra work in by crunching.
Unfortunately, productivity continues to decline over time as extra hours are put in, and while there is a limit to the number of additional work hours that can be put in, there is no practical limit to the reduction in productivity -- it can go negative, and do so in spectacular fashion (insert gratutitous story about wiping out codebase or fragging development machines here).
Determining the breakeven point is hard: programmer productivity is a complex and difficult measurement that most companies are simply not willing to invest in. Programmers themselves have concerns that some artificial measure will be applied to their performance reviews. Managers who know programmers have concerns that programmer behavior will be modified to "game" any artificial measure to the detriment of some nebulous "actual productivity". As someone who's been both a manager and a programmer, I think both concerns have validity.
I could write extensively about specific measures of output, but suffice to say that it is a difficult task and there is no commonly accepted rigorous measure (especially in the games business) of programmer output, and thus none of productivity (output per unit time).
In light of this lack I fall back upon my personal experience: crunching (50+ hour work weeks) has limited utility to most projects. After only 2 - 4 weeks of crunch most programmers have lost so much productivity that they are getting 40 or less hours of "real work" done. From a project point of view, they would be getting at least as much real work done if they dropped back to 40 - 50 hour weeks, and from a personal point of view they would be much healthier and happier. And they would be saving something up for that next crunch time.
By now, we've all read that cathartic LiveJournal entry (or the reposting here on slashdot) by an angry EA widow who has had her husband, her family life, and her own career co-opted by the hellish product development environment that has become the norm at Electronic Arts. Most of us in the business know, right down deep in our ulcers and migraines, exactly what she's talking about. Too many of us have been caught in "normal" development cycles that require overtime as a matter of course; and have been at the mercy of abusive managers who ratcheted us up to several months of 13-hour-a-day/7-day work weeks. Perversely, these managers always claim that this is what's required to make the schedule - and (the mendacity of this part is always breathtaking) to prevent our work hours from expanding even more in the future.
These stories are nothing new to me. I spent my 20s living them - and my 30s figuring out how to avoid ever doing that again.
Let me begin by establishing my bona fides. I've been building software for more than 20 years. Fifteen of those years were in the games business; half of those years were spent at EA's Bay Area offices as an external developer and an employee. I've held just about every technical position from tool programmer to director of engineering. As a programmer I've worked by myself and on teams of almost a hundred engineers. As a manager at a Fortune 100 company (Adobe) and elsewhere, I ran teams of up to 25 people, working on up to five projects at once. I've managed multi-million dollar art-intensive games, single developers, and core technology teams responsible to as many as eight clients (all with different requirements and all on different shipping schedules). Over the course of my career, I've been "in charge" (i.e. the senior engineering or project manager) on more than a half-dozen published titles, and held up the technical direction or project management end on over two dozen more.
In all that time, for all those titles, no project I was in charge of has ever missed its ship date or overshot its budget.
Yet I absolutely refuse to work the kind of death march hours ea_spouse describes. And I have never, ever asked or allowed my employees to do so.
Her story - and others that have been shared in the industry-wide conversation that her post provoked - make it clear that EA's management believes, as a matter of institutional principle, that only way to make money at games software is to create tight schedules, and the only way to make a tight schedule is to work your employees harder.
Decades of software engineering research and best practices - and my own experience - prove conclusively that this belief is complete bullshit.
Slashdot Mirror
Also as an American currently living in Canada, I must disagree. Canadian healthcare is FAR superior.
Canadian healthcare does the job -- everyone has a basic level of care. For specialized services that are not life threatening, you wait. In the US, if you are fortunate enough to have good insurance, you can fight your way through the system and get care...once. After that, you're hosed unless you manage to keep insurance through your work, because you'll never get insurance personally again.
My wife waited 3 months for a gynecological procedure in Bellingham, WA before we moved. She's been waiting for 5 months or more here in Vancouver for a possible knee procedure.
Emergency medicine is exactly the same here except that you don't get a multithousand dollar bill at the end of the experience.
Our last complete year in the US, we paid over $14,000 US for medical insurance. In BC, we pay about $1300 CDN. The $5K CDN or so in extra taxes we paid saved us a bunch of money.
And BTW, only 2% or so of Canadians ever avail themselves of US healthcare, despite claims that Canadians flock to the US to get care they can't get on time in Canada. Just ain't so.
Over more than 20 years as an independent developer (mostly in games), technical director at EA, manager in game software development, and manager in non-game software development (core technology), I've managed to plan, estimate, schedule, and deliver software on time without resorting to long-term crunch. Not only did I write the Crunch Mode paper we're discussing, I've been speaking (at GDC and elsewhere) and writing on the general subject of improving development practices for well over 12 years -- since the early 90s, in fact.
In my experience, proper line and project management can correct for failures of initial planning, requirement creep, and even poor scheduling. Of course there are limits: one can't deliver a full-fledged AAA game console product in a couple of weeks just because it's well managed. Of course there are challenges: game development is harder to predict because the elusive "fun" quality is even harder to design than the "useful" or "elegant" qualities that must be in other, non-game, software.
But one common practice that I've encountered which proper line and project management cannot correct for is cultural reliance upon crunch mode. Poor planning can be overcome: willful or ignorant mismanagement on the ground cannot.
Computer and console game software develoment goes back well over 20 years.(I know. I was there.) In the beginning, pretty much everything we did was ad-hoc. Now a lot of it is decently estimated and scheduled, but a lot of it is still not well-managed.
Crunch mode is a symptom of that management failure, not a result of any inherent intractibility of game projects. I've made a career of delivering projects (most of them games) with minimal slip and almost no crunch mode. It can be done.
Actually, it's a coding manager's attempt to rationalize insane behavior :-).
:-).
I don't believe that management is happy that crunch mode happens. I do think they want to maximize output, but that's kind of an assumed desire, because what they really want is to produce product that makes a lot of money. Making product that sells well is one branch of that ultimate desire, and reducing the costs of product is another. I don't think management sits around constantly asking "how do we maximize the output of our workers". But maybe they should
I think the major disconnect is the idea that hours in seats is a good proxy measurement for total useful output. This idea is the basis for the decision to use crunch mode (although I'm pretty sure it's rarely expressly stated). It's an idea that's widely discounted by experienced workers and managers (even those who use crunch mode routinely) and the studies agree that it should be discounted. You can say that crunch isn't the problem -- that there are a whole host of reasons why crunch happens -- but the crunch mode technique is, in and of itself, a problem because it actually delivers the opposite of what is wanted when it's used -- more output.
So poor planning is a contributor, but it's not the essential problem. The essential problem is failure to understand that the result of long-term crunch mode is lower total output.
Obviously one can program 80 hours a week. The question is whether you should.
There are clearly two sides to the question: is it good for the programmer to program more hours? and is it good for the project for programmers to program more hours? It's not necessary to pretend that these are the same question: there are exceptionally important projects with close deadlines (see Marc Stiegler's David's Sling for a fictional example) where the end result is so important that destroying programmers is acceptable collateral damage so long as the project is completed within a very tight time frame.
So: is it good for the programmer to program more hours in a week?
On average, no. Sure there are some programmers who can maintain an 80 hour week indefinitely, but the modal programmer will suffer loss of productivity as well as undesirable physical and mental side effects after some period of extended additional work.
Studies as far back as the first decade of the 20th century have demonstrated lessened productivity and increased accident rates with 10 hour work days compared with 8 hour work days. Modern studies of stress and sleep deprivation show that losing as little as an hour of sleep a night can have an effect similar to taking one or two stiff drinks.
Personal experience suggests that there is an average threshold after which effects become more severe -- somewhere between two and four weeks of 50+ hours. That doesn't mean there are no effects earlier, it's just that the effects become more obvious with time and hours.
How about the project? Is it beneficial to the project to work more hours?
In some limited cases, yes. As productivity (output per unit time) decreases, increased work time can result in an actual increase in productive output. So if you really need to have something done next week, you can get extra work in by crunching.
Unfortunately, productivity continues to decline over time as extra hours are put in, and while there is a limit to the number of additional work hours that can be put in, there is no practical limit to the reduction in productivity -- it can go negative, and do so in spectacular fashion (insert gratutitous story about wiping out codebase or fragging development machines here).
Determining the breakeven point is hard: programmer productivity is a complex and difficult measurement that most companies are simply not willing to invest in. Programmers themselves have concerns that some artificial measure will be applied to their performance reviews. Managers who know programmers have concerns that programmer behavior will be modified to "game" any artificial measure to the detriment of some nebulous "actual productivity". As someone who's been both a manager and a programmer, I think both concerns have validity.
I could write extensively about specific measures of output, but suffice to say that it is a difficult task and there is no commonly accepted rigorous measure (especially in the games business) of programmer output, and thus none of productivity (output per unit time).
In light of this lack I fall back upon my personal experience: crunching (50+ hour work weeks) has limited utility to most projects. After only 2 - 4 weeks of crunch most programmers have lost so much productivity that they are getting 40 or less hours of "real work" done. From a project point of view, they would be getting at least as much real work done if they dropped back to 40 - 50 hour weeks, and from a personal point of view they would be much healthier and happier. And they would be saving something up for that next crunch time.
By now, we've all read that cathartic LiveJournal entry (or the reposting here on slashdot) by an angry EA widow who has had her husband, her family life, and her own career co-opted by the hellish product development environment that has become the norm at Electronic Arts. Most of us in the business know, right down deep in our ulcers and migraines, exactly what she's talking about. Too many of us have been caught in "normal" development cycles that require overtime as a matter of course; and have been at the mercy of abusive managers who ratcheted us up to several months of 13-hour-a-day/7-day work weeks. Perversely, these managers always claim that this is what's required to make the schedule - and (the mendacity of this part is always breathtaking) to prevent our work hours from expanding even more in the future.
i ves/2004/11/11/643#more-643
These stories are nothing new to me. I spent my 20s living them - and my 30s figuring out how to avoid ever doing that again.
Let me begin by establishing my bona fides. I've been building software for more than 20 years. Fifteen of those years were in the games business; half of those years were spent at EA's Bay Area offices as an external developer and an employee. I've held just about every technical position from tool programmer to director of engineering. As a programmer I've worked by myself and on teams of almost a hundred engineers. As a manager at a Fortune 100 company (Adobe) and elsewhere, I ran teams of up to 25 people, working on up to five projects at once. I've managed multi-million dollar art-intensive games, single developers, and core technology teams responsible to as many as eight clients (all with different requirements and all on different shipping schedules). Over the course of my career, I've been "in charge" (i.e. the senior engineering or project manager) on more than a half-dozen published titles, and held up the technical direction or project management end on over two dozen more.
In all that time, for all those titles, no project I was in charge of has ever missed its ship date or overshot its budget.
Yet I absolutely refuse to work the kind of death march hours ea_spouse describes. And I have never, ever asked or allowed my employees to do so.
Her story - and others that have been shared in the industry-wide conversation that her post provoked - make it clear that EA's management believes, as a matter of institutional principle, that only way to make money at games software is to create tight schedules, and the only way to make a tight schedule is to work your employees harder.
Decades of software engineering research and best practices - and my own experience - prove conclusively that this belief is complete bullshit.
Read the rest at: http://enginesofmischief.com/blogs/ramblings/arch