2.1 What Is XP?

XP is based on four key principles: simplicity, communication, feedback, and courage. This section introduces each principle, and the remainder of this chapter touches on each concept where appropriate.

2.1.1 Simplicity

Simplicity is the heart of XP. Applying the principle of simplicity affects everything you do, and profoundly impacts your ability to successfully apply XP. Focusing on simple designs minimizes the risk of spending a long time designing sophisticated frameworks that the customer may not want. Keeping code simple makes changing code easier as the requirements inevitably change. In addition, adopting simple techniques for communicating requirements and tracking progress maximizes chances that the team will actually follow the process. Most importantly, focusing on simple solutions to today's problems minimizes the cost of change over time. Figure 2-1 shows that the intended result of XP practices is to tame the cost of change curve, making it increase much less over time than we would otherwise expect.

Figure 2-1. Cost of change on an XP project

Traditional theory argues that software becomes increasingly expensive to change over the lifetime of a project. The theory is that it is ten times harder to fix a mistake of requirements when you are in the design phase, and 100 times harder to make changes late in a project during the coding phase. There are many reasons. For one, there is more code to change as time goes on. If the design is not simple, one change can affect many other parts of the system. Over time, as more and more programmers change the system, it becomes increasingly complex and hard to understand.

The XP approach recognizes that the cost of change generally increases like one would expect, but this increase is not inevitable. If you constantly refactor and keep your code simple, you can avoid ever-increasing complexity. Writing a full suite of unit tests is another tool at your disposal, as described later in this chapter. With complete regression testing, you have the ability to make big changes late in the development cycle with confidence. Without these tests, the cost of change does increase because you have to manually test everything else that you may have just broken.

There are other forces in XP projects that balance the rising cost of change. For example, collective code ownership and pair programming ensure that the longer an XP project goes, the better and deeper understanding the whole team has of the whole system.

2.1.2 Communication

Communication comes in many forms. For programmers, code communicates best when it is simple. If it is too complex, you should strive to simplify it until the code is understandable. Although source code comments are a good way to describe code, self-documenting code is a more reliable form of documentation because comments often become out of sync with source code.

Unit tests are another form of communication. XP requires that unit tests be written for a vast majority of the code in a system. Since the unit tests exercise the classes and methods in your application, source code for the tests become a critical part of the system's documentation. Unit tests communicate the design of a class effectively, because the tests show concrete examples of how to exercise the class's functionality.

Programmers constantly communicate with one another because they program in pairs. Pair programming means that two programmers sit at a single computer for all coding tasks; the two share a keyboard, mouse, and CPU. One does the typing while the other thinks about design issues, offers suggestions for additional tests, and validates ideas. The two roles swap often; there is no set observer in a pair.

The customer and programmer also communicate constantly. XP requires an on-site customer to convey the requirements to the team. The customer decides which features are most important, and is always available to answer questions.

2.1.3 Feedback

Having an on-site customer is a great way to get immediate feedback about the project status. XP encourages short release cycles, generally no longer than two weeks. Consider the problems when the customer only sees new releases of your software every few months or so. With that much time in between major feature releases, customers cannot offer real-time feedback to the programming team. Months of work may be thrown away because customers changed their minds, or because the programmers did not deliver what was expected.

With a short release cycle, the customer is able to evaluate each new feature as it is developed, minimizing the necessity to rework and helping the programmers focus on what is most important to the customer. The customer always defines which features are the most important, so the most valuable features are delivered early in the project. Customers are assured that they can cancel the project at any time and have a working system with the features that they value the most.

Code can offer feedback to programmers, and this is where good software development tools shine. In XP, you use unit tests to get immediate feedback on the quality of your code. You run all of the unit tests after each change to source code. A broken test provides immediate feedback that the most recent change caused something in the system to break. After fixing the problem, you check your change into version control and build the entire system, perhaps using a tool like Ant.

2.1.4 Courage

The concepts that were just described seem like common sense, so you might be wondering why it takes so much courage to try out XP. For managers, the concept of pair programming can be hard to acceptit seems like productivity will drop by 50%, because only half of the programmers are writing code at any given time. It takes courage to trust that pair programming improves quality without slowing down progress.^[1]

^[1] Check out http://www.pairprogramming.com for more information on the benefits of pair programming.

Focusing on simplicity is one of the hardest facets of XP for programmers to adopt. It takes courage to implement the feature the customer is asking for today using a simple approach, because you probably want to build in flexibility to account for tomorrow's features, as well. Avoid this temptation. You cannot afford to work on sophisticated frameworks for weeks or months while the customer waits for the next release of your application.^[2] When this happens, the customer does not receive any feedback that you are making progress. You do not receive feedback from the customer that you are even working on the right feature!