Summary
In a recent blog post, Ron Jeffries extols the XP virtue of sustainable effort, including limiting a developer’s work day to eight hours. While a laudable objective, it is also unrealistic. Trusting the process and visions of success are more important for a sustainable project than shorter work hours.
Advertisement
In his recent blog post, Impact of Overtime on Productivity, Ron Jeffries extols the XP virtue of "sustainable effort"—the pace at which a team can produce results for longer periods of time. His notion of sustainable effort contrasts with the often stop-and-sprint stints so common in a project-based work environment. Project deadlines imply tangible deliverables - in other words, work that, really, must be completed. I have never seen a project where pressure would not mount with the approach of a deadline, leading to both increased work hours and stress.
According to Jeffries, such cramming before a deadline is counterproductive, since it lowers productivity and increases defects. Instead, a project should proceed at an even pace and at a sustainable rate from start to finish.
While that's a laudable objective, I think it's about as realistic as expecting smoothly flowing traffic on a Los Angeles freeway. After all, if everyone just drove at the same speed, there really would be no reason for traffic to back up other than for the occasional accident or road hazard. As a theory, however, it doesn't pan out more than a utopian theory of economics conforms to the realities of human nature. The real world is messier—people are messier and are not always rational. Hence, there will always be traffic jams, and there will always be project crunch.
A more useful theory of sustainable effort should consider the messy aspects of a software project, and help us become more productive in that context. Given that there will always be project deadlines, and hence long hours required to bring a project to conclusion, how can we maintain a high level of productivity while putting in those long hours?
Jeffries points to mounting pressure as a culprit in reducing productivity because, according to Jeffries, pressure causes well-established processes to break down:
A common effect of putting teams under pressure is that they will reduce their concentration on quality and focus instead on "just banging out code". They'll hunker down, stop helping each other so much, reduce testing, reduce refactoring, and generally revert to just coding. The impact of this is completely predictable: defect injection goes way up, code quality goes way down, progress measured in terms of net working features drops substantially.
While that may be true in some projects, I do not see a necessary correlation between pressure and long work hours, and a break-down of established processes. In many ways, processes become even more important when working long hours and under pressure, since fatigue can lead to absent-mindedness and hence sloppiness. The processes are there to guard against the effects of such sloppiness.
This is evident in the work of emergency workers who must excel in their results under extreme pressure. That is precisely why a pilot in distress must “fly by the book,” and why ingrained automatic responses are the main objective of training firefighters, police offers, and paramedics.
The work of such emergency personnel is sustainable not because they clock out after eight hours of work (just ask any emergency room doctor), but primarily because they value the processes that are there to ensure a quality outcome. Indeed, improving the effectiveness of an emergency room team—or a software team—is often a matter of improving the processes and then training the participants to respect and follow those processes.
An effort becomes unsustainable if it produces unacceptable results, or if its participants burn out and quit. Poor quality results and burnout are often locked in a deadly embrace, one feeding on the other. A team that consistently produces unacceptable results will burn its members out, no matter if team members work two hours a day or twelve. On the other hand, nothing is more exhilarating than shipping a hit product—even if it demanded sixteen-hour workdays for a while. At least, after a successful product launch, team members can relax in style on the Riviera, a privilege not afforded to members of the less successful team.
Sustainable effort and long work hours, therefore, are not mutually exclusive. Instead, sustainable effort requires the right processes in place, and the trust that those processes will lead to success even in the face of pressure. More than anything, team members must be confident at a deep, psychological level, that their working hours lead to success—and managers should help their team members visualize that success. Envisioning a project’s success in concrete, tangible ways more than makes up for the occasional lost sleep that that success demands.
> <p>While that's a laudable objective, I think it's about > as realistic as expecting smoothly flowing traffic on a > Los Angeles freeway. After all, if everyone just drove at > the same speed, there really would be no reason for > traffic to back up other than for the occasional accident > or road hazard. As a theory, however, it doesn't pan out > more than a utopian theory of economics conforms to the > realities of human nature. The real world is > messier—people are messier and are not always > rational. Hence, there will always be traffic jams, and > there will always be project crunch. </p>
I'm not sure that it's important to your point but I think if you consider this, you will realize it is not the case.
Just like fluid flowing through a pipe, there is a limit to how many cars per minute a road can accomodate at a given speed limit.
Generally when you are travelling from the suburbs into a more densely populated area, there are not only more cars, the roads have a lower capacity. Any time that the amount of cars being funneled into the system exceeds the capacity, you will see a slowdown.
Yes, people can cause backups by just not travelling the prevailing speed but if the traffic is not close to capacity, those aberrations tend to smooth out prety quickly.
Any yes, I've thought about this a little too much but there's not much else to do when sitting in traffic at a nice bottleneck.
I agree that it's a matter of balance and context.
I tend to be suspicious of calendar-based rules that are supposed to produce optimal peformance. Sometimes you should work less than 8 hours, sometimes more. Sometimes you need to build multiple times in one day, sometimes you should wait a few days, etc.
A process that is tailored to your particular environment and project can incorporate more knowledge than following a generic edict and thus is more likely to be effective.
I feel people should work 4 days a week or 6 hours a day. It's all a matter of perspective and diversity of perspectives should be respected. Some guys have no life outside work and for them work is life. If those guys want to work 12 hr days, more power to them. But developers should not be in a position where there is management or peer pressure to work more than 8 hours a day.
I have been working 40 hour weeks and have been very productive. I feel sane (or maybe I should say, more sane). My body doesn't ache. I don't have RSI flare up. When I'm at work I am likely to be nicer to others because I'm not tired. I have more patience for questions and requests and I am generally more open minded as a result of being less tired and stressed.
When I was working 60 hours a week, my body would ache. I had hard time falling asleep at night from stress. I had no personal life and my family life was falling apart (my wife was very angry at me for working so many hours). I would at times be unreasonably angry at my coworkers even though no one is at fault. I would NOT have an open mind and would be more likely to insist that the bug is not in my code, but rather is somewhere else. And so on.
Frankly, I think even 40 hours a week is overkill, but anything over 40 is immoral and unethical. Many of my coworkers died in the past few years and their deaths really remind me of how precious and short life is, and how important it is not to let your job, peers and management overwhelm you. I feel that work environment is partly responsible for some of my corworkers' early demise.
Industrial cost engineering textbooks often include tables describing relationships between productivity and length of the work day, but studies on quality show that work days of a set length actually hinder overall productivity. Enpowering people to work shorter days to keep fresh, or longer days to take advantage of creative bursts help make the creative bursts more frequent. Other studies have shown, independent of industry, a group that works overtime for over two weeks straight will be less productive than a team that just works 40 hours weeks for those two weeks.
Of course, we're software developers that have played games during the day between meetings so we could work in the evening without interruption until midnight or later. I get most of my coding done in the afternoon and evening. I show up during the day to interact with clients and fellow workers.
Am I wrong to summarize your theory as saying that consistently working 60+ hour weeks will *not* lead to burnout if you always "produce acceptable results"? I would argue that instead burnout is only delayed.
So, I suggest that the human cost of burnout is high enough that the long hours are just not worth it. If you hired me, I would insist to be paid time and a half during overtime - roughly an extra $50 / hour. After all, I'm inching towards burnout and that's a pretty heavy personal cost. I'd be happy to *share* that cost with my employer during a stressful sprint. That ought to cut down the incentive for abuse that exists now.
> Am I wrong to summarize your theory as saying that > consistently working 60+ hour weeks will *not* lead to > burnout if you always "produce acceptable results"? I > would argue that instead burnout is only delayed.
No, that's not what I was saying. I simply said that *occasional* long stints don't necessarily have to lead to lower productivity and burn-out.
Having to work 60+ hours consistently would tell me that there is something seriously wrong with the organization, i.e., that management is either incompetent (wasting resources), or cowardly (trying to get away with minimum investment into people). In either case, that wouldn't sound like a good place to work at.
At that's just the point. If I have a feeeling each work day that I'm working with either incompetent or cowardly managers, even a 6-hour work day over a few years could burn me out. That's true even if I was getting paid a lot of money for that work.
But working with a team that I'm convinced is creating something that will truly make a difference, and a team that I know at a deep level will succeed, working longer hours for a while, just to bring a product to market, will not cause me to burn out, provided that I have outstanding managers who can help me visualize that success during the process, and who can make that success a reality within a not too long time period.
In other words, I'd argue that burn-out is caused not so much by long work hours, but by work that does not produce the desired results.
One reason for that may be that by working with an excellent team and outstanding leaders, I'd probably feel that I'm benefiting on a daily basis by learning and becoming more capable each day. And the team's success would just be a concrete manifestation of that increased ability.
I realize, though, that this might apply more in the context of startup companies than in a more traditional corporate environment. Adding feature X to the HR department's Web site just does not have the same effect as believing that you're creating the next Google.
Is there any other "profession" where this is even a question?
I know tax accountants work long hours during tax season (ending April 15 in the USA), but do accountants talk about whether 60-hour weeks are appropriate in other times of the year? No.
Do you want a surgeon operating on your at the end of a 60-hour week? (And the USA should do what Australia did and limit the hours worked by residents/interns.)
"The reaction time of residents who had just finished a month of heavy work schedules was 7 percent slower and they committed 40 percent more errors than when they were on a month of light schedules"
"The effects of fatigue are thought to play a part in almost two-thirds of the road accidents in the United States, say the authors. Extended working hours, shift work, and lifestyle choices are likely to decrease the amounts of sleep we have, they conclude. The effects, which are likely to be cumulative, pose a serious risk to safety"
"Where a work schedule of 60 or more hours per week is continued longer than about two months, the cumulative effect of decreased productivity will cause a delay in the completion date beyond that which could have been realized with the same crew size on a 40-hour week."
> > Am I wrong to summarize your theory as saying that > > consistently working 60+ hour weeks will *not* lead to > > burnout if you always "produce acceptable results"? I > > would argue that instead burnout is only delayed. > > No, that's not what I was saying. I simply said that > *occasional* long stints don't necessarily have to lead to > lower productivity and burn-out.
Then I'm not sure your position is so different from Jeffries. I don't think he says to *never* work more than 40 hours. I think he's criticizing those that have made it a *normal* practice.
> I realize, though, that this might apply more in the > context of startup companies than in a more traditional > corporate environment. Adding feature X to the HR > department's Web site just does not have the same effect > as believing that you're creating the next Google.
Now, if I believe that I'm creating the next Google, and I'm going to get a share of what I'm creating, and I don't have a family to spend time with, then heck yeah, I'm in for the long hours. Risking burnout to reach retirement quickly could be a better bet.
May I ask how old they were? I'm sorry for your loss. My job currently does the usual ebb and mega-flow, with lately us coders running > 50 hours/week. I think like Sommers is advocating, we're a team where more hours doesn't necessarily mean more defects, but I am concerned about the health effects. I find shortness of breath much more common in my life now that I do long hours. It's a scary idea that simply coding is killing me, and I've been trying to force myself to jog on the weekends.
I have been building commercial software since '88. I've worked lunatic hours (100 hour weeks for one company for a short while) and I have worked sensible hours.
And it is all true - long hours produce worse results. Steady and sustainable produces dramatically higher quality and I have to say I do my utmost not to run teams I am managing in non-sustainable ways.
The whole - Surely if you worked longer hours? is just management think. They are interested in ticking boxes and fighting fires at another point in time rather than dealing with the issue now. And THAT is the big lesson I have learned. You WILL have to deal with the problem - working longer hours will usually move it to the future but the shit will still hit the fan. You are better off taking the hit now and focusing on doing a good job with a team that are happy and can just keep on going for as long as it takes.
I like the water through a tube analogy. You can always increase the pressure in the tube, but eventually you will dilute your services. If you replace my vodka with water, I will notice!
Furthermore, if Marcus Holliman is working 60 or 80 hour weeks, he's contributing to a culture of error in the IT sector. Want to know one of the reasons that programming deadlines are so impossible to reach? They are based on 8 hour days. If you say to a manager "I can get that done in a week," the manager adds 40 hours to the development schedule. Unfortunately, you probably meant "I can get than done in 80 hours." Time estimation erros like that pile up pretty quickly and ruin life for everyone else.
The 40-hour week is one of the original 12 eXtreme Programming practices. It is meant to interlock with the other XP practices to gain orders of magnitude improvement in productivity. This practice was later modified by Kent Beck into the concept of sustainable pace. There are good reasons to aim for a 40-hour week in XP because the intensity of the development is much greater than most developers are used to. Also there is nothing in XP that prevents overtime. The guideline is that overtime should not occur two weeks in a row, or otherwise become sustained overtime. To imply as Frank does that XP developers do not "value the processes that are there to ensure a quality outcome" is silly.
The available research demonstrates that people are less effective in intense intellectual activity over a long period. Even someone as energetic as Tom Peters says he can only manage six hours before his intellectual effectiveness drops off. While certain motivated individuals can sustain long, intense work hours (think entrepreneurs and friends), the reality is that a team of developers will not sustain that type of work effort. Pushing the team to work sustained overtime under pressure is a recipe for disaster.
Of course, I did not imply that people should work long hours - in fact, regularly working long hours, I think, are to a great extent a sign of an ineffective work environment (or an ineffective person).
My point was merely that a good organization or team has procedures in place that guard against most errors that can occur as a result of fatigue due to long work hours. Many of the XP practices, in fact, are designed as such guards, e.g., pair programming, test-driven development, etc.
Flat View: This topic has 24 replies
on 2 pages
[
12
|
»
]
Previous Topic
