James on Software: The Crunch Mode Paradox: Turning Superstars Average
Reg Braithwaite
· 1 year ago
Thanks for the quote and the link!
Controversial indeed... I myself do not always refuse the bidding of stake holders, even when I believe they are wrong. But I do insist that they understand the trade-offs they are making before trying practices I believe to be unproductive, such as sustained overtime.
It doesn't always help, but I often try to crack a joke to make the point. In the case of crunch mode, my standard line is:
"No problem. I can do almost as much work in seventy hours as I can in fifty."
James Golick
· 1 year ago
I almost never refuse the bidding of stake holders either. It's funny, though, we'd really be doing them a favour.
The whole thing is just so damn backwards, it's crazy.
Thanks for the comment!
Travis Jensen
· 1 year ago
You can't push back when management thinks "it's crunch time" and expect to have any effect. Instead, you need to be continually educating about how software engineering really works through the entire process, until management begins to understand it is bridge building and not a factory floor.
Crunch time for one week is OK (because it will spill into the second week, which is also OK, but just barely). After two weeks, you run into the exact problems you mention.
And, honestly, if you cannot move management to that understanding...well, I don't want to work where I'm a clerk. :)
anon
· 1 year ago
i have to disagree slightly with the author.
sometimes crunch mode is necessary. if something doesn't get done and the company wont' get paid, you have to put your ideals aside and get the code working, best practices be damned.
around 6 months ago, i was involved in a long (~3 month) 'crunch' on a project for a major financial company, with developers often putting in 60-70 hour weeks. at one point i did > 100 hours which is insane and almost certainly was counter productive to an extent.
however, the work got done, and it *never* would have got done with people doing 40 hour weeks. not just developers either - QA, business analysts and project managers all worked like crazy.
i should point out i didn't do this voluntarily for the love of the company - i am a contractor and was paid by the hour, as was everyone else involved. this helped a lot. i can largely thank this extended 'crunch' for my new house :-)
anon2
· 1 year ago
anon,
You're right about some things having to get done. But the real question is why that thing had to get done in that little time. The answer always ends up being "mismanagement". So this essay is still relevant, and something that managers still need to understand.
Reg Braithwaite
· 1 year ago
I must admit I have trouble with the argument that "it's an emergency, it's critical." That makes it sound like an exceptional circumstance. Ok, if that happens on one project out of ten or twenty, fine. But when it happens on every milestone of every project, you have to step back and stop pretending there is an emergency and recognize that you are managing *for* this outcome.
Imagine, if you will, the question of performing open-heart surgery on an overweight forty year-old smoker with blocked arteries/aorta/whatever. Obviously, it's an emergency, get out the knife.
But if the same person is back in twenty-four months for more surgery, and they haven't lost weight, they haven't stopped smoking, what are you to say? Clearly this is no longer "emergency surgery," the patient is choosing a course of action that will end up with surgery.
Kevin Scaldeferri
· 1 year ago
@anon: "and it never would have got done with people doing 40 hour weeks"
Really? Just what was it about working 70-80 hour weeks that produced an infinite increase in productivity?
anon
· 1 year ago
i largely agree with the sentiment in the original essay, just not the school of thought that its *always* the wrong thing to do. sometimes you have to roll up your sleeves and get on with it.
>>ou're right about some things having to get done. But the real question is why that thing had to get done in that little time. The answer always ends up being "mismanagement
business critical project related to financial legislation, software had to comply with it. not my call and i'm not saying its right, but that was the driver.
>Really? Just what was it about working 70-80 hour weeks that produced an infinite >increase in productivity?
the work wouldn't have got done in 9-5. it's hard for someone that wasn't part of it to understand the situation, so i'm afraid you'll have to take my word for it. if everyone had clocked out at 5 and not put in any extra effort it's extremely unlikely the project would have been succesful.
my point was, a large team of dedicated people rescued a project that was 'in a mess' by essentially doing a prolonged crunch. at the end of it, everyone got a nice bonus and big holiday, and nothing like it has happened since.
it's worth pointing out that during said crunch there was a real sense of camaraderie - noone had 'lost the will to live'. if people were pressured into the work, that would have been a different ball game.
but my original point is sometimes crunches work.
AkitaOnRails
· 1 year ago
What James says is not news but it is amazing how often we end up caught on this trap. It's easier than someone from the outside - with a cool head - can think of. It is so obvious that hurts. But it happens, all the time. It's actually the net result of a chain of small bad decisions and wrong attitudes/expectations down the road from the management, the client and the developers. No one person does it wrong alone: it's a chain reaction and starts in a very innocent way and it scalates very very fast like a snow ball speeding up down hill. I've been in crunch mode for some time now and I feel very very burnt out and exhausted.
Something similar was already said more than 30 years ago by some guy named Fred Brooks ...
Rafael Alvarez
· 1 year ago
Yes, crunches work some times. The interesting thing is identifying why those "some times" it works.
I have been in a very unique position, as I have seen crunches that worked, and crunches that didn't on the same team (same people, same project).
When management declares "crunch time", and the team feels that the plan was impossible to begin with, and that it was known since the beginning, the crunch will fail (low morale, low productivity, etc,etc,etc). But if the team feels that the plan was achievable, and that what happens is just a roadblock in an otherwise clean road, they will "do their best" to hit the deadline anyway (programmers are stubborn optimistic beasts). Management must just take care that no one burns out due to overwork, the sense of purpose will give the morale and energy needed.
So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.
Anon
· 1 year ago
cite. So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.
All Comments
Controversial indeed... I myself do not always refuse the bidding of stake holders, even when I believe they are wrong. But I do insist that they understand the trade-offs they are making before trying practices I believe to be unproductive, such as sustained overtime.
It doesn't always help, but I often try to crack a joke to make the point. In the case of crunch mode, my standard line is:
"No problem. I can do almost as much work in seventy hours as I can in fifty."
The whole thing is just so damn backwards, it's crazy.
Thanks for the comment!
Crunch time for one week is OK (because it will spill into the second week, which is also OK, but just barely). After two weeks, you run into the exact problems you mention.
And, honestly, if you cannot move management to that understanding...well, I don't want to work where I'm a clerk. :)
sometimes crunch mode is necessary. if something doesn't get done and the company wont' get paid, you have to put your ideals aside and get the code working, best practices be damned.
around 6 months ago, i was involved in a long (~3 month) 'crunch' on a project for a major financial company, with developers often putting in 60-70 hour weeks. at one point i did > 100 hours which is insane and almost certainly was counter productive to an extent.
however, the work got done, and it *never* would have got done with people doing 40 hour weeks. not just developers either - QA, business analysts and project managers all worked like crazy.
i should point out i didn't do this voluntarily for the love of the company - i am a contractor and was paid by the hour, as was everyone else involved. this helped a lot. i can largely thank this extended 'crunch' for my new house :-)
You're right about some things having to get done. But the real question is why that thing had to get done in that little time. The answer always ends up being "mismanagement". So this essay is still relevant, and something that managers still need to understand.
Imagine, if you will, the question of performing open-heart surgery on an overweight forty year-old smoker with blocked arteries/aorta/whatever. Obviously, it's an emergency, get out the knife.
But if the same person is back in twenty-four months for more surgery, and they haven't lost weight, they haven't stopped smoking, what are you to say? Clearly this is no longer "emergency surgery," the patient is choosing a course of action that will end up with surgery.
Really? Just what was it about working 70-80 hour weeks that produced an infinite increase in productivity?
>>ou're right about some things having to get done. But the real question is why that thing had to get done in that little time. The answer always ends up being "mismanagement
business critical project related to financial legislation, software had to comply with it. not my call and i'm not saying its right, but that was the driver.
>Really? Just what was it about working 70-80 hour weeks that produced an infinite >increase in productivity?
the work wouldn't have got done in 9-5. it's hard for someone that wasn't part of it to understand the situation, so i'm afraid you'll have to take my word for it. if everyone had clocked out at 5 and not put in any extra effort it's extremely unlikely the project would have been succesful.
my point was, a large team of dedicated people rescued a project that was 'in a mess' by essentially doing a prolonged crunch. at the end of it, everyone got a nice bonus and big holiday, and nothing like it has happened since.
it's worth pointing out that during said crunch there was a real sense of camaraderie - noone had 'lost the will to live'. if people were pressured into the work, that would have been a different ball game.
but my original point is sometimes crunches work.
Something similar was already said more than 30 years ago by some guy named Fred Brooks ...
I have been in a very unique position, as I have seen crunches that worked, and crunches that didn't on the same team (same people, same project).
When management declares "crunch time", and the team feels that the plan was impossible to begin with, and that it was known since the beginning, the crunch will fail (low morale, low productivity, etc,etc,etc). But if the team feels that the plan was achievable, and that what happens is just a roadblock in an otherwise clean road, they will "do their best" to hit the deadline anyway (programmers are stubborn optimistic beasts). Management must just take care that no one burns out due to overwork, the sense of purpose will give the morale and energy needed.
So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.
Amem to that. Very true.