The 12 Practices of Extreme Programming

Extreme Programming, or XP, is a software development approach built on the premise that, when done right, the cost of changing software is constant. In other words, implementing a feature today will not be cheaper then implementing it in the next release. It's therefore not critical (nor realistic) that your team designs the perfect system in its first iteration.

Kent Beck, the creator of XP, introduced the process as a collection of 12 fundamental practices. Few of these practices are new, but collectively, they reinforce each other and allow you to deliver systems on time, according to specs, within budget and, more importantly, maintain a constant cost of change.

The rest of this article briefly explains these 12 fundamental practices.

Practice #1: Make The Customer Available

For XP to be successful, the customer must be available. And by available, I don't mean that you can email or play phone tag with him and get an answer within the next few days. This customer must be on site and accessible to everyone on the XP team. When developers have a business related question and need a face-to-face meeting to get an answer, they must be able to do so in minutes, not days.

The customer's main responsibility is to write user stories and later prioritize the features. The technical team can suggest areas of improvements and even write user stories themselves if they wish, but the customer is the one who has the final word regarding when/if to implement these user stories. Do not undermine his/her authority. In other words, do not add functionality unless it is required by the customer and covered in a user story.

The customer's secondary responsibility is to verify the features as soon as you consider them to be complete. This early involvement offers 3 advantages:

• It will facilitate the eventual acceptance of the product.
• It provides you with early and ongoing feedback. If the customer does not feel the software meets his/her needs, he/she can communicate it immediately. He/she can therefore modify and/or add user stories that will be considered for the next iteration.
• It shows progress to the customer, which is an important aspect of relationship management (which is beyond the scope of XP).

Since the customer plays a critical role in the XP team, it's important that he/she be an expert who truly understands the behavior required from the system. Having a junior person represent the customer can lead you in the wrong direction and might do more harm than good. If the customer is not willing to send a senior representative or if too many customers are involved, use a customer proxy (e.g. a Product Manager) to make business decisions on behalf of the customer(s).

Practice #2: Plan the Release

Once the customer or his/her proxy has written all the user stories, the technical team sizes them. The customer can then prioritize the user stories based on their level of importance and the effort required to implement each one of them. This is another prime example where technical people make the technical decisions and business people make the business decisions. People should not confuse their roles, and it's partly up to you, the project manager, to ensure it.

The release can have a fixed time or scope. In the first case, a deadline is set and the customer selects which user stories he/she wants implemented given the available timeframe. In the second case, the customer determines which user stories are mandatory and the technical team determines the release schedule.

Practice #3: Plan For No Overtime

Whether you plan the release given a fixed time or scope, the team should not have to work overtime. Make sure you include derivative activities such as document reviews and vacations in your project schedule.

Occasionally, a developer might have to work late to fix a bug discovered at the 11 th hour, but this case should represent the exception and not the rule.

Practice #4: Release Frequently

Iterations should be released every 1 to 3 weeks.

The short release cycles have various advantages. First, it shows progress to the customer and allows you to receive continuous feedback. In addition, the customer might be ok with, and willing to circumvent, certain bugs and usability issues if he/she knows that his team will get another release within 1-3 weeks. He can require the bugs to be fixed in the next release, or suggest change requests in the form of (you guessed it) user stories.

Regular releases are also easier on developers and project managers. As I'm sure you'll agree, a one-month release is much easier to manage than a one-year one.

Practice #5: Simplify Your System Design

A simple design always takes less time to implement than a complex one – at least in the long term. So always use the simplest design possible to meet the user stories.

An important distinction here is that “simple” does not mean “easiest” or “first come to mind”. In the short term, a simple design will most likely require more refactoring than a “first come to mind” design. But for the cost of change to remain constant, which is one of the basic principles of XP, the design must be simple and flexible. Otherwise, implementing additional user stories will become a nightmare.

Design a system that solves the customer's current needs. Don't overcomplicate your design to meet requirements that you think the customer might want in the future. Designing and implementing user stories that have yet to come costs money. Since no one can accurately predict the future, the extra effort spent designing these future requirements is largely a waste of time. Always ask yourself “Can I simplify the design and still meet the user stories?” If so, do it.

Practice #6: Refactor Regularly

Refactoring is a fancy word for improving the design of existing code without changing its behavior. Refactor your code regularly.

Whenever you're done with a feature, refactor your code. Eliminate repetition. Make sure everything is expressed once and only once. Break up long functions into smaller ones. Keep your code clean, concise, and well commented. In other words, let your system design emerge through refactoring.

This is a very effective approach, but it requires discipline and courage. Refactoring is a pay me now or pay me later – with interest practice. I've seen so many projects over the years where designers are rushed from one feature to another with no time to refactor their code. After a couple of years using such a style, the application gets so messed up that designers prefer to start a new project from scratch instead of trying to add functionality to the existing application.

Practice #7: Agree on Coding Standards

Adopt or develop coding standards to help designers understand each other's code and simplify refactoring. Many designers rewrite their peer's code because they don't like the location of curly braces or indentation. Following coding standards will eliminate such wasted refactoring effort.

If standards already exist for a given programming language, adopt it. If not, develop your own. Start with simple rules such as the placement of braces, indentation, and length of lines. Then move on to the naming of methods and constants.

Practice #8: Develop a Common Vocabulary

Develop a common vocabulary to improve communication. Choose a system metaphor to name classes and methods consistently, thereby making it easier for everyone to understand the component. Being able to guess what a component is/does by its name if very important for code reuse, refactoring, and to understand the system's design. This in turn helps maintain a constant cost of change.

Practice #9: Code the Unit Test First

Writing the unit tests before implementing the feature has many advantages. An obvious one is that by the time you're done the feature, you'll have all the proper unit tests. Whether your boss pulls you off the project as soon as you're done coding the feature or you just get lazy, the tests will be there.

Furthermore, even the most detailed functional specs will never be as comprehensive as unit tests. Think of your unit tests as your specs. If you can write the unit test, then you know exactly which behavior to expect from the feature, and isn't that the purpose of functional specs?

Once your test is written, write the least amount of code necessary to make the test pass. If it means refactoring some of the existing code so you can reuse it, go ahead. But don't build any functionality that is not required by the unit test.

Practice #10: Program in Pairs

This method is definitely the most counter intuitive one of XP. In fact, it's so counter intuitive that in most cases, when people discuss XP, pair programming is all they talk about.

The practice is simple. While the person at the keyboard implements the feature, his/her partner strategically plans how the feature fits in the overall design and which existing components can be reused.

When designing a complex feature, two people working on a single computer will add as much functionality as two people working separately. But the main advantage of pair programming is not to save time but rather to increase the quality of the system and simplify its design; two important factors to maintain a constant cost of change.

Pair programming offers other huge advantages:

• The peer pressure forces the individuals to apply themselves even more and follow the other XP practices.
• It gives developers a chance to learn from their peers.
• It ensures transfer of knowledge throughout the team.

I strongly recommend that you mix the pairs up regularly. Otherwise, cliques will quickly form, thereby reducing some of the benefits of pair programming.

Practice #11: Adopt Collective Code Ownership

The entire code base belongs to the team and not a single individual. When individuals own code, it can't be modified unless its owner approves of the change, or implements it him/herself. This creates a serious bottleneck, especially when the owner is busy or away on vacation.

As soon as a feature is built, release it to the team where it can be maintained and enhanced by anyone. And don't worry about a junior developer messing up the code or not reusing it properly. It's not going to happen if everyone programs in pairs.

Practice #12: Integrate On a Daily Basis

Integrate and release your code as often as possible, preferably every few hours, but certainly at least once a day.

If you can't commit your code at least once a day, chances are your design is overly complicated. You've most likely written methods and functions that are too complex, and you should refactor your code.

Integration should not be a long, unpredictable phase that occurs near the end of the project. Those of you who integrate on a regular basis will agree that it's much easier to merge and fix bugs when you've only written code for a day than for a month.

Conclusion – The Whole Is Greater Than the Sum of Its Parts

As explained in the second paragraph, the 12 practices explained above reinforce each other. They are most effective when followed collectively. That's why it's important that you understand every single one of these practices if you're serious about XP.

You can't let a junior designer refactor a critical part of the system. It's therefore important that junior developers pair up with seniors. And you can't implement the simplest design possible to meet the current iteration's user stories if you don't plan to refactor your code when new features are added.

Read this article once or twice more if you're serious about XP, and four times or more if you're not. This is a process worth understanding, and you don't want to negate it without understanding it completely.

 

Looking for more information on Extreme Programming? Visit our Recommended Books section, or simply ask us.