Quoting TMMM as a justification for product death march? Wow.
A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you're back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).
Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we're at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.
One of the points of TMMM is that communication and coordination overhead is a cost and a risk and that it grows exponentially in relation to the number of programmers you have. So, you won't get double the productivity out of twice as many programmers (unless they're on unrelated projects--but more projects == more overhead as well).
200 hour weeks would be quite unsustainable, indeed. Forget not sleeping, where do you get the other 32 hours?
I was wondering whether anyone would catch on ;)
Anyway, I wasn't arguing that more developers is easier (I do believe it might be better) - I was saying that piling hours on top doesn't scale either.
MMM is actually an important part of the answer, and it is unfortunate that it was presented this way (death marches are deprecated for their own reasons.) The right way to think of this is to consider four people each working two hours a day on the same problem. Sustained effort and focus matter.
This is most true for tasks that are more intellectually demanding, like the development of large-scale software (which is what Brooks was writing about.) The more routine a task is, the easier it is to divide it up (though that is rarely to the benefit of the worker.)
Maybe it's because I'm a little bit over forty, but for me only a few days working 10 hours a day (plus a significant commute) decreases my productivity significantly. That is at least if I have to work on more that one project at a time. If I don't have to switch tasks and it is relatively straightforward work I can probably manage for a few weeks, but not much longer and I know that I'll definitely hate my life.
If the project is fun I can work two times as long without fatigue. For example if I think this is important and my effort personally can make the difference. Or if I am using a new technology or something that feels like a "portfolio" piece.
I'm naturally a sprinter type, so I tend to set up my work the same way. I tend to work more in the winter (55+ hours) since there isn't much else to do anyway, and work less during the summer (40 or less). I'll also work like you suggest for multi-month stretches and then take a few weeks off and go on vacation.
I've tried the steady working, but I just do not operate that way. When there is work to do I do it, and simply have a hard time sitting still or concentrating on something else.
I'm fortunate to be in a field and with a company that is flexible in this way. I also really like this method. When I'm on vacation that is my 100% focus. I'd much rather work a lot and then completely unplugged instead of always working even on vacation.
At which point they ragequit. But hey, never mind the burnout, let's just find another cog for the machine. Never mind the ramp-up cost - fifty-five hours a week, yeeehaw!
I wouldn't be so harsh. If you are young, and if you breathe, drink and eat your product, this could be awesome. None of that lasts forever, of course, but if it happens - what a time to be alive! Not a place for everyone, indeed, and not conventional.
If, on the other hand, you are only interested in the product, and/or you have other stuff to take care of, that would be Hell on Earth for you.
do you get a lot of actual work done? I found communication slows things done a lot. waiting on answer from other people seems to be a pretty big bottle neck. I like to have a couple project going at once to be more productive.
I get very little of "real" work during regular hours, most of it goes in meetings, code reviews and of course communication. I code during the off hours essentially two jobs i guess, one I love(coding) makes the other(management) bearable .
A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you're back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).
Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we're at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.