Why crunch mode doesnt work




















Finally, we will more specifically address software development, showing that workers in this field may in fact be even more susceptible to the decreases in productivity brought on by overwork than workers in many other fields. Quite a bit of research over the past century has studied the relationship between hours worked and productivity.

Although to our knowledge no research has been performed relating hours worked to productivity in software development, studies in other fields have consistently arrived at two conclusions:. A large number of studies dating back to the early s support these conclusions. Over a century ago Dr. Ernst Abbe conducted experiments relating working hours to output in his Zeiss Optical Works factory in Germany. Hugo Muensterberg's seminal article "Psychology and Industrial Efficiency" states about Abbe's work:.

Ernst Abbe, the head of one of the greatest German factories, wrote many years ago that the shortening from nine to eight hours, that is, a cutting-down of more than 10 per cent, did not involve a reduction of the day's product, but an increase, and that this increase did not result from any supplementary efforts by which the intensity of the work would be reinforced in an unhygienic way.

This conviction of Abbe still seems to hold true after millions of experiments over the whole globe. Abbe discovered that shortening work hours while keeping working conditions unchanged led to an increase in total output. This result has been confirmed again and again in various areas of industry. At that point, the costs strongly begin to outweigh the advantages. When you return them to a hour week, their output will be sub-par for some time while they recover.

At An extra Colonel Gregory Belenky, the Director of the Division of Neuropsychiatry at Walter Reed Army Institute of Research, does research for the Pentagon on maximizing the productivity and alertness of soldiers under combat conditions. Sleep-deprived individuals are able to maintain accuracy on cognitive tasks, but speed declines as wakefulness is extended.

Throughout the 36 hours, their ability to accurately derive range, bearing, elevation, and charge was unimpaired. However, after circa 24 hours they … no longer knew where they were relative to friendly and enemy units. They no longer knew what they were firing at.

Early in the simulation, when we called for simulated fire on a hospital, etc. Later on in the simulation … they would fire without hesitation regardless of the nature of the target. One of the biggest productivity sinks created by Crunch Mode is the increase in the number of errors produced. The longer you crunch, the greater your odds of creating a big, expensive, schedule-busting monster.

Longer hours or, especially, insufficient sleep as little as hours less per night does serious damage to their ability to use those brains productively. It has been well known for a long while how intimate the relations are between fatigue and industrial accidents.

In a study on the effects of sleep deprivation, investigators at the University of Pennsylvania found that subjects who slept four to six hours a night for fourteen consecutive nights showed significant deficits in cognitive performance equivalent to going without sleep for up to three days in a row.

Yet these subjects reported feeling only slightly sleepy and were unaware of how impaired they were. Studies have shown that being awake for 21 hours impairs drivers as much as having a blood-alcohol concentration of 0. Most software companies will fire an employee who routinely shows up drunk for work. In fact, they will demand that these people work to the point of legal impairment as a condition of continued employment. The risks are real — and the errors made can be truly catastrophic.

From The Promise of Sleep by Dr. William Dement, pp The night of March 24, was cold and calm, the air crystalline, as the giant Exxon Valdez oil tanker pulled out of Valdez, Alaska, into the tranquil waters of Prince William Sound. The huge tanker ran aground, spilling millions of gallons of crude oil into the sound. The final report of the Rogers Commission on the Space Shuttle Challenger accident said that the decision to launch made during a critical teleconference was flawed.

It comes down to productivity. Workers can maintain productivity more or less indefinitely at 40 hours per five-day workweek. When working longer hours, productivity begins to decline. Somewhere between four days and two months, the gains from additional hours of work are negated by the decline in hourly productivity. In extreme cases within a day or two, as soon as workers stop getting at least hours of sleep per night , the degradation can be abrupt.

Many of the studies quoted above come out of industrial environments, and it may be argued that the more creative mental work of programmers, artists, and testers is fundamentally different. In fact, it is different, and Colonel Belenky explicitly addresses that :. In contrast to complex mental performance, simple psychomotor performance, physical strength and endurance are unaffected by sleep deprivation. The ability to do complex mental tasks degrades faster than physical performance does.

Among knowledge workers, the productivity loss due to excessive hours may begin sooner and be greater than it is among soldiers, because our work is more affected by mental fatigue. A hundred years of industrial research has proven beyond question that exhausted workers create errors that blow schedules, destroy equipment, create cost overruns, erode product quality, and threaten the bottom line.

They are a danger to their projects, their managers, their employers, each other, and themselves. Any way you look at it, Crunch Mode used as a long-term strategy is economically indefensible. Longer hours do not increase output except in the short term. Crunch does not make the product ship sooner — it makes the product ready later.

Crunch does not make the product better — it makes the product worse. The fourth one is probably only a matter of time. They crunch because they have learned only the importance of appearing to do their best to instead of really of doing their best. And they crunch because, back when they were programmers or artists or testers or assistant producers or associate producers, that was the way they were taught to get things done.

In fact, the literature shows, over and over again, that it is the very worst way. Managers, shareholders and employees all stand to benefit from time-tested management practices that will deliver better products, sooner, less expensively — and with less wear and tear on human resources and public reputations.

As I noted, almost all the documents cited here are available on the Web. While much more data is available in the print literature, I more or less deliberately selected from online studies that the reader can access and use immediately. Here is a collected list of documents I have either quoted from or consulted extensively. Evan Robinson started in the game business at 19 as a developer for TSR.

By 22, he was building computer games as an independent developer for EA. He lives in Vancouver, BC. Log-In Join Now! History In — almost a century ago — industrial efficiency pioneer Ernst Abbe published in Gessamelte Abhandlungen his conclusions that a reduction in daily work hours from nine to eight resulted in an increase in total daily output.

What Management Wants What is management is trying to achieve when it sends employees off on death marches? As far as I understand, the experiments show explicitly less work done , as in, if you do the 60 hour workweek for prolonged time, then you have less widgets produced per week, period. It's NOT a tradeoff of more volume for less quality and increased risk. All the drawbacks you list are valid, and come on top of less total productivity.

You don't get a product built faster but with more defects and technical debt. You get the product built slower; with more defects and techical debt; and at a cost to the workers personal life in a true lose-lose tradeoff. Elon probably has built up a huge support system around him that he knows, both implicitly and explicitly, has his back and will help him out.

At least I was paid hourly at the time. Entrepreneurs are, by definition, outliers. I don't think it makes much sense to compare them to -- or include data for them in -- an analysis of the average worker.

Symmetry on Aug 26, parent prev next [—]. It really depends what you're doing. For me, meetings don't result in nearly the same mental fatigue as coding does. JoeAltmaier on Aug 26, root parent next [—].

One meeting can depress me for half a day. But I can get in a coding thrall and go 4 or 5 hours without noticing time pass. I hear you. I hate having scheduled meeting almost every day, early, that ramble about things that usually don't affect me. My time would have been better spent still in bed until it was time to start building coding, designing, writing, etc.

The question is does it matter more to produce the most defective products, or to produce stuff that works? That's why other industries don't do "crunch mode. The best idea would be to accept that it will take longer, but that fails flat for political reasons. Bad situation. I got the impression, that most people are aware, that there is only a finished software or a date, even if they are non-technical.

They got something, even if it's bug-ridden, which they can show and sell someone. And the fixes can be made between the "finish date" and the "first real use". The software that is ready after the finish date just has to work for presentations.

They do. The finance industry, particularly around the front desk, is notorious for freakishly long working hours. As outlined in the post, that way of working, doesn't shouldn't work.

Especially when the code produced, or in the case of traders decisions made, might lose vast amounts of money due to a single mistake. I'm curious, if anyone here works in that kind of an environment - How does this work? Are these numbers exaggerated? Are you all on stimulants? Do you see the kind of creeping errors and codebase decay one might expect? AFAIK it's more about signalling - demonstrating commitment to your peers and superiors. Not in that industry, but working at a startup founded by two ex banking albeit software guys.

A little bit of the culture has come along for the ride. Absolutely - finance uses hours the same way software uses open-source projects created in your spare time.

People I knew that worked that much, used to spend a lot of time blankly staring at screen or chatting about weather after few weeks. The rest and socialization they were missing out of work somehow creeped into work.

I do not think they were aware of the effect, it is just that everything took them somewhat longer time. It may seen silly but the article could use a brief description of what's "crunch mode" since it was a new term to me.

Edit: I would posit that short bursts of overtime - perhaps a single hour week at the ramp up to a major release can actually be helpful if not exciting - if used quite sparingly. Research on that theory would be more interesting to me.

Short bursts of overtime is not crunch. Crunch is by definition long term. Anyway, I recall that you can actually raise short term productivity for up to four weeks or so, but expect lower output following weeks.

The productivity falls if crunch runs longer then six weeks. Not sure about in between. That was just one study, so take it or leave it. Last note: if you have hour work weeks before every major release, then there is something wrong with your planning or process. In any case, it does not sounds like the release will be much tested before shipment. Crunch is longer than usual work with a looming deadline. Crunch doesn't have to be long term. Crunch can be working for 7 hrs seeing you are going to make your goal and busting ass for 3 more hours.

Crunch should be "doable". What the author was describing is a death-march. The goal isn't to arrive at a location but to kill as many people as possible in the journey. Ref, trail of tears.



0コメント

  • 1000 / 1000