Coding Standards

All shops have a coding standard. In many shops, the coding standard is not written down but is implicitly understood by the development team. And in a few shops, no one is cognizant that there is a standard. But there is always a standard, it’s just a matter of degree.

The loosest, most chaotic standard is that “everyone is doing Java,” but past that, everyone is on their own. From there, standards move up through concerns over formatting (where do the curly braces go?) to naming (no Hungarian notation!), to variant use of constructs (use the global import form), to general guidelines (methods should generally be no longer than 12 lines).

Whether your shop needs to recognize and adhere to stricter standards is a matter for your team to decide. In a purely emergent, evolutionary environment, the coding standard will mature out of consistent teamwork and continual review. When starting a new project, most teams will want to spend a few minutes to an hour discussing the things they are concerned about. Changes to the standard should be expected, as should exceptions to whatever the rules might be.

Why Standards?

What is the importance of a standard? One could argue that developers are a creative lot and should be allowed to code however they please. While this might be fine for a high-capability, hot-shot shop, it causes lost time and creates code that is more difficult to maintain.

Working with code that poorly or inconsistently adheres to standards is an aggravation that may not seem like such a big deal for the here and now. But the constant, low-level dissonance builds up into a nuisance over the course of your development day. Just as riding on a noisy road will make most people considerably more tired at the end of a day trip than riding over a smooth road, reading inconsistent code will wear you down more quickly. (I also suspect that if all code looks exactly the same, the monotony will wear you down as well. But if your code all looks exactly the same, you probably have a duplication problem…)

There is some corollary evidence: everything written about design and readability for web sites says that you don’t want to use more than a few font sizes, you generally don’t want to use multiple fonts, you should use a consistent and small color palette, each page should be consistently organized like each other page, and so on. Restricting designers to a reasonable set of consistency standards has in no way stifled the creative design of web sites. If this is true for web design, then it should also hold true for coding.

Arguments about formatting can often be resolved via use of most modern IDEs, such as Eclipse, that allow for automatic formatting of source code based on numerous settings. Individual developers can reformat code to their liking, as long as they check it in with the accepted standards after changing it.

But things like naming and organization cannot always be easily reconciled. If one developer uses Hungarian notation for modifications to a class that did not previously, the resulting code is a mess. If I have to look at the top of a class for the instance variables, while in another class I look at the bottom, and in yet another I have to look between the methods (urk!), the code does not consistently communicate things. Time spent understanding the code increases, and the likelihood of overlooking something important also increases.

Yes, tools (IDE) may help you reorganize and rename, but having to spend time to work with the tools do so is an additional investment with questionable cost. It’s a lot easier and cheaper to just get it right in the first place.

Developers should recognize that a coding standard is about consistent, clear communication more than anything else. If it’s not important to your shop to communicate ideas in a consistent fashion, tightening up your a coding standard is not essential. If you want one more technique toward bulletproof code, a better coding standard is a simple place to start.

Sustainable Pace

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.1

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.”2

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.

1Lovaasen, Grant. “Brokering With eXtreme Programming,” XP Universe 2001.

Atom