Why crunch mode doesnt work six lessons

The old saw about "if builders built buildings the way programmers build software, the first woodpecker to come along would destroy civilization" isn't quite right, but at least most buildings do what they're supposed to do -- they stand up and the keep the water and the wind out. We can't say that about most software projects -- not only are they late and over budget, they very often don't do what they're supposed to do.

There's a pretty good argument that it's not just hard but impossible to meaningfully measure programmer output. The conventional source-level measures are all language dependent and easily game-able and all, or nearly all, programmers like to game systems.

Function point-like measures are incredibly heavy and often don't deal well with really interactive software like, say, games. Feature level measures are so fuzzy as to be essentially useless.

About the only output measure that's not complete shite is bugs finding and fixing , and even that is about much more than just programmers -- the efficiency of your QA organization has a lot to do with it as well. In many ways, software development is not a science but an art, and it's notoriously difficult to measure art. Why Crunch Mode Doesn't Work. Like Print Bookmarks. Jan 10, 3 min read by Ben Hughes. In a blog post of a disgruntled spouse of an employee of an international electronic games company, sparked a mountain of media coverage and on line discussion.

Evan Robinson picks up the mantle with an article for the IGDA on 6 reasons why crunch mode doesn't work: Productivity varies over the course of the workday, with the greatest productivity occurring in the first four to six hours.

After enough hours, productivity approaches zero; eventually it becomes negative. Productivity is hard to quantify for knowledge workers.

Five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century. What makes us think that our industry is somehow exempt from this rule? At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.

Multiple consecutive overnighters have a severe cumulative effect. Error rates climb with hours worked and especially with loss of sleep.

Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?

Indeed the evidence for the 8 hour day, 5 days a week has been around and in practice since When Henry Ford famously adopted a hour work week in , he was bitterly criticized by members of the National Association of Manufacturers. But his experiments, which he'd been conducting for at least 12 years, showed him clearly that cutting the workday from ten hours to eight hours — and the work week from six days to five days — increased total worker output and reduced production cost.

Ford spoke glowingly of the social benefits of a shorter work week, couched firmly in terms of how increased time for consumption was good for everyone. But the core of his argument was that reduced shift length meant more output. So what elements are there to this that ends up affecting the software industry so much? Commonly projects are planned on the flawed assumption that there is a fixed amount of work to be done - a common mistake named the ' lump-of-labour fallacy ".

Agile methodologies such as Scrum avoid making this assumption, although this doesn't avoid the end of iteration crunch, it does cap the crunch time to a percentage of the iteration. So, if we as managers know this is wrong, why does it keep happening? The author poses his viewpoint: Managers decide to crunch because they want to be able to tell their bosses "I did everything I could.

They crunch because they haven't really thought about the job being done or the people doing it. 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.

Esther Derby has a different view point - that is we fail to plan for what could go wrong : We go through stages of understanding the problem—we gather requirements, develop analysis models, and then design software solutions. We develop plans to build and deploy the solution.

That implies that some individuals can in fact work 50, hour weeks for months without a significant drop in productivity, and some probably shouldn't work more than 4 days a week. Or, to add in the more specifically measured element: 40 hours is the peak of the Laffer curve [productivity being inversely proportional to hours worked a week].

I have absolutely no data on variance for the peak of the Laffer curve if you imagine attempting to gather this data, you'll notice it is extremely difficult. That being said, despite this lack of data, I have heard a lot of people claiming they can work a whole lot more and get more and more done. I do not believe their ad hoc methods have secretly outsmarted science.

Fishkins on Aug 26, root parent prev next [—]. Correct me if I'm wrong, but I believe the research actually only shows the peak is no higher than 40 hours per week. Are there studies indicating people are more productive working hour weeks than 30 or hour weeks? Of course your point still stands, they'd just have to be even more of an outlier. AhtiK on Aug 26, parent prev next [—]. If the daily work is built around being in the flow and rhythm then mental muscle is not that much stressed.

You wake up, you know that your limo is waiting in 20 minutes. You'll start with a scheduled call on the way to gym. At the gym personal trainer makes sure you're giving maximum. Then the limo takes you to the private jet so you can catch the conference in Europe at 4pm. You just stop wasting non-work time over the weekend and use it for maximum recovery and family-time. Roboprog on Aug 26, root parent next [—]. Karunamon on Aug 26, root parent next [—]. Most of the day to day crap that most of us deal with can be automated or delegated away.

Rapzid on Aug 26, parent prev next [—]. I suspect sleep, and routine, is more the determining factor. That leaves enough time for an 11 work day, 1 one hour workout, 30 minutes of commute, and 2. As a single persons game. Real world statistics probably reflect that most people either aren't capable or simply wouldn't maintain this kind of routine. PeterisP on Aug 26, root parent next [—]. Experiments have repeatedly shown a solid increase in day-total productivity when going from 10 hour workdays to 8 hour workdays; similarly, there is an increase in total weekly productivity when comparing 6 days a week to 5 day workweek.

I doubt that the people who work[ed] on saturdays had a much different daily routine than those who didn't; but still, working that extra day only results in less work done. No, no less work done in total. As others have mentioned before, this trick can work very well in the short term. Everybody will try to catch up by staying an hour later, or working on the weekends The problem is that cause and effect are so far apart in time that nobody notices why this is happening.

Usual suspects such as "rusty codebase" or "technical debt" get assigned with the blame and no lesson is learned. 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. 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. After enough hours, productivity approaches zero; eventually it becomes negative. Lesson Three: Five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century.

What makes us think that our industry is somehow exempt from this rule? Lesson Four: At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.

Multiple consecutive overnighters have a severe cumulative effect. Lesson Six: Error rates climb with hours worked and especially with loss of sleep.

Eventually the odds catch up with you, and catastrophe occurs.