5 ms·

To "just work harder", in this case 36 hours, is the easy decision to make when something goes wrong. It smells deliciously of heroics, bravado and top performe

by MortenK 14y ago

To "just work harder", in this case 36 hours, is the easy decision to make when something goes wrong. It smells deliciously of heroics, bravado and top performer mentality. Most importantly, the soul drenching, exhausting late hours, gives the illusion that "we are doing all that is humanly possible to resolve the problem". How tough are we, right? But as the author points out, heaps of literature clearly show that "crunching", like it's affectionately called in the games industry, is contra-productive. One guy working 8 hours, going home for a good sleep, and coming back to work an additional 8 hours will vastly outperform the developer-turned-zombie that's been at it for 24 hours straight. At that point, short term memory is gone, stupid mistakes (blunders even) are rampant. Fixing simple issues takes extraordinary amounts of time, because the ability to focus is all but lost. You effectively have tunnel vision and your reactions and logical skills are reduced to that of a drunk. This is not anecdotal - there are an immense amounts of studies done on the subject. But time and again, the knowledge gets discarded because it's just easier to "work through the night" at a frantic pace, rather than take the necessary step back, let people rest and do the work in an orderly and planned manner. By burning the candle in both ends, at least no one can challenge your commitment to solving the problem. While it may sound counter-intuitive to go to bed while the house is on fire, it is, at least if 40 years of research is to be believed, actually the only correct thing to do in a software development crisis. Note this doesn't mean "stick 100% to 8 hours and always go home at 17.01", but it does mean if you are still there at 23.00 you are much better off going home, getting sleep and resuming work when well rested. The games industry seem to be especially vulnerable to this problem. It might be due to the general inexperience level caused by games development being a young mans game, or it might be due to a failure to understand that games, while glorified in the industry, is "just" software, and therefore also subject to all the established rules of software development. In any case, I agree with the author that Molyneux should know better than to tweet from the rooftops how many hours everybody is working, but I guess he is not thinking entirely straight after 36 hours of work.

jacquesm 14y ago
It depends on whether or not a fix is perceived to be further away than what you can accomplish in that one night. Being down for yet another business day when you don't have to be ('house on fire') is usually not an option. There is also a class of problems (chasing subtle bugs) that you're much better equipped to tackle when you come in fresh in the morning or when you're actually not looking directly for them, the flip side is there are those that it takes forever to get the mental model set up that maps the circumstances of the bug with enough resolution that you have a chance of cracking them that it pays off to just sit there until it's done, even if that means staying up well past your bed time. The rule seems to be 'go home if you can no longer positively contribute towards solving the problem', not just 'go home'.
- MortenK 14y ago
  That's a reasoning that is prevalent and very often catch project managers and developers alike: It is "not an option" going home, because of whatever crisis is occurring. Because if we aren't working through the night, we are not committed, and we are certainly not doing the most we can to resolve the crisis. The outcome is almost always stereotypical: Early in the morning, the fire is doused, and all is good. Until suddenly three more fires spring up out of nowhere, previously undetected due to fatigue and tunnel vision on the one particular issue that got it all started. Slow and careful consideration of the problem, the potential fixes and especially the side consequences of implementing those fixes, gets thrown out the window after 24 (or even 12) hours of coding. I agree in theory that the best solution would be if you could somehow tell when you are no longer positively contributing, and only then going home. But it is exceedingly hard, if not impossible, for an individual to accurately determine when he is no longer positively contributing towards solving the problem (i.e. Creating more problems that is being fixed). The outcome is you have people valiantly soldiering on, in the false belief that they are actually contributing, but with actual, measurable setbacks being incurred due to fatigue.
  - jacquesm 14y ago
    Some things just can't wait. If you have never worked in an industry where there are no commitments to outsiders then that's all fine and good but production (banks, networking, airlines, critical infrastructure such as electricity plants, water pumping, hospitals and a very large number of other services that society relies on) problems take precedence over a lot of otherwise completely valid concerns. If that is a recurring theme then there is definitely a deeper problem but on occasion things go wrong and 'going home' really isn't an option. Count your blessings if you are not stress resistant and are working in a line of business where these things don't matter. Production problems have a habit of not announcing their arrival dates, and some of those can be surprisingly hard to track down to their root cause. Working until the problem is fixed in those situations has nothing to do with 'showing commitment' it has everything to do with being committed. There is a right time for knowing when to call it quits and there is a right time for pushing on until the lights are back on. You simply can't categorically state that it is wrong to push on, it depends on what is on the line and the capabilities of the people involved.
jheriko 14y ago
Actually what is established by literature is that crunch /does/ work, but that it has disproportionate payoffs and only works on teams which already work 40 hours or less per week and haven't been recently crunching... e.g. 60 hours doesn't give you 1.5x productivity over 40, maybe 1.2x, and 80 hours is even worse return for investment... ... however it then impacts future productivity, i.e. you should take a couple of days at least after a crunch, and expect to still not be performing at peak for a couple more weeks of doing 40 hours.

by MortenK 14y ago

jacquesm 14y ago

It depends on whether or not a fix is perceived to be further away than what you can accomplish in that one night. Being down for yet another business day when you don't have to be ('house on fire') is usually not an option. There is also a class of problems (chasing subtle bugs) that you're much better equipped to tackle when you come in fresh in the morning or when you're actually not looking directly for them, the flip side is there are those that it takes forever to get the mental model set up that maps the circumstances of the bug with enough resolution that you have a chance of cracking them that it pays off to just sit there until it's done, even if that means staying up well past your bed time. The rule seems to be 'go home if you can no longer positively contribute towards solving the problem', not just 'go home'.

MortenK 14y ago
That's a reasoning that is prevalent and very often catch project managers and developers alike: It is "not an option" going home, because of whatever crisis is occurring. Because if we aren't working through the night, we are not committed, and we are certainly not doing the most we can to resolve the crisis. The outcome is almost always stereotypical: Early in the morning, the fire is doused, and all is good. Until suddenly three more fires spring up out of nowhere, previously undetected due to fatigue and tunnel vision on the one particular issue that got it all started. Slow and careful consideration of the problem, the potential fixes and especially the side consequences of implementing those fixes, gets thrown out the window after 24 (or even 12) hours of coding. I agree in theory that the best solution would be if you could somehow tell when you are no longer positively contributing, and only then going home. But it is exceedingly hard, if not impossible, for an individual to accurately determine when he is no longer positively contributing towards solving the problem (i.e. Creating more problems that is being fixed). The outcome is you have people valiantly soldiering on, in the false belief that they are actually contributing, but with actual, measurable setbacks being incurred due to fatigue.
- jacquesm 14y ago
  Some things just can't wait. If you have never worked in an industry where there are no commitments to outsiders then that's all fine and good but production (banks, networking, airlines, critical infrastructure such as electricity plants, water pumping, hospitals and a very large number of other services that society relies on) problems take precedence over a lot of otherwise completely valid concerns. If that is a recurring theme then there is definitely a deeper problem but on occasion things go wrong and 'going home' really isn't an option. Count your blessings if you are not stress resistant and are working in a line of business where these things don't matter. Production problems have a habit of not announcing their arrival dates, and some of those can be surprisingly hard to track down to their root cause. Working until the problem is fixed in those situations has nothing to do with 'showing commitment' it has everything to do with being committed. There is a right time for knowing when to call it quits and there is a right time for pushing on until the lights are back on. You simply can't categorically state that it is wrong to push on, it depends on what is on the line and the capabilities of the people involved.

jheriko 14y ago

Actually what is established by literature is that crunch /does/ work, but that it has disproportionate payoffs and only works on teams which already work 40 hours or less per week and haven't been recently crunching... e.g. 60 hours doesn't give you 1.5x productivity over 40, maybe 1.2x, and 80 hours is even worse return for investment... ... however it then impacts future productivity, i.e. you should take a couple of days at least after a crunch, and expect to still not be performing at peak for a couple more weeks of doing 40 hours.