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.

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.

Talk Back!

Have an opinion? Readers have already posted 24 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.