XP is often defined by the dozen or so practices that comprise it. Pair programming, test-first design, planning game, metaphor, etc. It’s an interesting way to define a development process, as a bunch of simple practices that work together to form a greater whole. Waterfall, on the other hand, is defined by its phases, which are simply breakdowns of what is delivered over time. Analysis produces an analysis document, design produces a design document, and the completion of the implementation phase results in actual production software.

XP’s premise is that following a handful of simple rules—practices—over and over will result in solid product. The process is the same from project inception to completion. In fact, there is no such notion of inception or of any other phase within XP. Other processes such as RUP are insistent that there is a “full lifecycle” of development: a very clear start to the effort (inception), a demarcation of when it is complete (transition), and lots of definition for the phases in between (elaboration and construction).

40-Hour Week

One of the XP practices was originally defined by Kent Beck as the “40-Hour Week.” The basic idea is that programmers must be well-rested in order to produce quality work. The less rested a team, the more likely that they introduce defects into the software. There are studies that prove a few things, including the fact that working additional hours is not a one-for-one productivity increase. One study described an environment where the development team increased their work hours by 50% to 60 hours per week, but was only able to produce 20% more lines of code. Not only that, but the number of defects doubled.¹

In many software development environments, developers work far more than forty hours per week. Fifty and sixty hour weeks are common, and in the rush to meet deadlines, many developers find themselves clocking in far more. To some managers, developers who work forty hours per week are seen as doing only the minimum required to get by. In some shops, a culture is created where those who stay late and on weekends are the ones recognized as truly dedicated. A heavy time card becomes a badge of honor.

What is the value of these additional hours? Past some point, any additional time expenditure results in rapidly diminishing returns. The potential for mistakes rises dramatically as developers tire. More defects are introduced when developers are tired. Fixing these mistakes and defects can and will negate any benefit to having logged the extra hours.

Eight Hour Burn

As XP has matured, the names of some of its practices have changed. The phrase “40-Hour Week” had too many connotations and problems (not the least of which was an American cultural assumption), so the XP community searched for a replacement.

One of the suggested new names for “40-Hour Week” was “8-Hour Burn.” No different if you do the math, but the “burn” indicates that in a given day, there is only so much energy most people have to burn. That energy is used up after eight hours of solid work, and is replenished by the next morning, after some personal time and a good night’s sleep. This radical notion of an 8-hour work day is a model that has proven sustainability over long periods of time.

In fact, eight hours at any one activity is usually more than enough. Consider skiing as an example activity. In Colorado, ski lifts open at 9am and close at 4pm—only seven hours, not a lot of time considering the high lift ticket prices!

But the reality of skiing is that it is an activity that cannot be sustained for longer periods of time. No matter what level you ski at, your muscles can only hold up so long. You ski to your abilities: if you are a beginner, you are on the green (easy) slopes, but you are exerting a considerable amount of muscle power due to your inexperience. If you are an advanced skier, you are challenging yourself on the double black diamonds (expert) slopes, also exerting a lot of muscle power. Regardless of your ability, by three or four in the afternoon, the muscles in your legs are starting to turn to jelly. Most skiing accidents occur around this time of day. No matter how good a skier you are, it is easy to make stupid mistakes when you are exhausted.

So it goes with software development. After a solid day of coding, most minds are mush. Beck tells a story about a shop that discovered the bulk of their defects were introduced after 4:30pm. Stop! Go home, rest, come in refreshed and enthusiastic the next morning. Defects will decrease.

Sustainable Pace

Both terms 40-Hour Week and 8-Hour Burn have the same problem: they are defined by hard numbers. These numbers are certainly not internationally applicable, nor are they applicable in different environments, such as government shops.

The official term for this XP practice of being well-rested is now “Sustainable Pace.” The idea is that team members “work hard, and at a pace that can be sustained indefinitely.”²

The name “sustainable pace” is appealing from the standpoint that it suggests the ultimate goal of the practice. It doesn’t constrain a team to a narrow definition of what is a full day (or week) of work. If a team can sustain 50 hour work weeks without burning out team members, that is their pace. Government workers running at 37.5 hours per week won’t have to feel that they aren’t doing XP fully.

The sustainable pace practice is a good example of the benefits of defining a process by its practices. To explain this, let’s take waterfall as a counter-example.

In a waterfall world, there is a beginning and an end to our efforts. Waterfall postulates that if you do certain things at certain times (like doing lots of analysis up front), you shouldn’t have to revisit them. This life-cycle-based definition also assumes that given a starting point, there is a concrete amount of work that can be done by a given endpoint, and that we can always make it fit.

Well, you can usually “make it fit,” but this can involve some tradeoffs at the lower levels. If the project is running late, the best solution is to either extend the deadline, or negotiate the details of just what the customer expects to receive by that time. Unfortunately, the scope is not always negotiable.

In lieu of changing scope, another solution is to eliminate reviews, testing, refactoring, and other safeguards of software development, in order to get the work done in the allotted time. You can also make it fit through overtime.

Yet excessive overtime directly damages the notion of sustainability. There is plenty of evidence that people can get “burned out” by working excessive hours week after week. So overtime is not something you want to happen too often. (The general rule of thumb in XP is that developers cannot work more than one week of overtime in a row.)

Other solutions—elimination of refactoring, testing, etc.—will kill sustainability just as easily as overtime. A system that isn’t refactored constantly will turn to an unmaintainable mess. A system without tests becomes completely undependable over time, as new code introduces an unknown number of defects.

Successful software development hinges on the quality of what is produced. The problem of defining a process by deadlines is that deadlines don’t give easily. Instead, the quality controls give.

Practices and Sustainability

You want to be able to deliver software again and again, with success and predictability. This idea of a sustainable pace is one of the central drivers behind XP. Any development team can hack out gobs of code over a one-year period, but sustaining code much beyond this period is a costly and difficult proposition. I’ve seen shops throw away a million lines of code (and millions of dollars worth of investment). The software was so crufty that further development on it could not be sustained in a cost-effective fashion.

Many shops during the early-to-mid-90s tried to figure out a way of sustaining short iterations over time, an extremely difficult goal. There is just too much overhead if you try to fit an artifact-heavy waterfall process within a two- or three-week period. You might do it successfully for a few iterations, but it is oh so easy to start slipping things. One nasty bug discovered in the inspection meeting, and there’s no way to close out the iteration in time.

The overhead of an inspection cycle almost ensures impossibility for completion within two-week cycles. Having to throw untested code over the wall to be manually tested by a QA team means that you will soon run out of time to be able to test everything in an iteration. These two examples demonstrate the need for extreme practices, practices that build in the notion that we inspect things all the time (pair programming, collective code ownership), and that we specify the system through automated tests all the time.

XP provides a set of practices that, when done collectively, provide a framework that allows success. When its simple practices are followed, an emergent behavior arises that allows software to be predictably and successfully delivered over and over. We insist that each of these practices are done, because we know that not doing them will limit how long our software can survive.

By defining a process this way—from the ground up with a set of required practices—XP ensures that everything that must happen will happen. The process itself doesn’t allow for skimping on the essentials. The process itself is what allows for the delivery of quality software to be sustained over long periods of time.

Share your comment