2.5 Design

XP does not encourage a lot of up-front design. Instead, the XP approach recognizes that humans cannot accurately design every single feature of an application before writing code. So why not design a little bit right away and then write the code immediately? As a result, your customer can get his or her hands on some working software right away.

XP practitioners typically obsess about good design, taking it much more seriously than other developers. They simply have a different point of view on when to do it—all the time, instead of all at the beginning.

2.5.1 Design Today's Features

Customers define which features are most important, and programmers work on those features first. As each new feature is implemented, the application is delivered to customers and they have the opportunity to offer immediate feedback.

In this customer-centric delivery model, we do not have time to spend months and months of time doing detailed design and analysis. We also cannot afford to develop complex frameworks to accommodate every anticipated feature. If we did either of these things, we would not be able to deliver working code (and thus get feedback) to the customer in a timely fashion.

Figure 2-2 shows the relationship between time-to-customer and the likelihood that the finished product does not meet expectations. Stated simply, the longer you work in a vacuum without getting feedback from your customer, the higher the probability is that you will develop the wrong features.

Figure 2-2. Strive for short release cycles

This is where courage comes back into the picture. The best developers may have the most trouble accepting the fact that they should not worry so much about framework development. Instead, they should worry more about writing exactly what the customer wants today, along with extensive unit tests. The code may or may not be reusable, but we can resolve that later using refactoring techniques.

2.5.2 Simple Design

People on XP teams use a lot of index cards and whiteboards. Since you are only working on one small feature at a time, you rarely have to develop complex design models. Instead, you come up with a good design for the feature you are working on, and then you write your unit tests and code.

When you move on to the next feature, you do additional design work if necessary. The original design documents are generally not useful, because code can change and people rarely bother to keep design documents in sync with code, anyway. The code itself is the most reliable design document in existence. The next best thing is the unit tests, because they show how to use your code.

2.5.3 UML

Unified Modeling Language (UML) can be used on XP projects, but only to the extent that it helps you deliver requested features to customers. A UML class diagram can make it far easier to visualize the static relationship between classes, and a sequence diagram can make dynamic behavior much easier to see. The point is to make programming tasks easier, and nothing more. If you need to use UML to design the feature you are working on right now, then by all means work on that UML. But far too many project teams spend inordinate amounts of time perfecting diagram after diagram, only to find that the customer changed his mind after seeing the finished product.

2.5.3.1 UML tools

If you really want up-to-date UML diagrams, consider tools like JBuilder Enterprise Studio, Together Control Center, or Rational XDE. These types of tools can reverse-engineer your code and produce UML diagrams. These tools ensure that the diagrams stay in sync with your code. XP encourages you to throw away UML diagrams once you have written your code. With these tools, you can generate correct, current UML any time it is needed.

2.5.3.2 Whiteboards and scratch paper

You don't need fancy, expensive UML diagramming tools. A stack of index cards, a whiteboard, or even a scrap of paper can serve as a surprisingly effective design tool. Here is the process:

This may seem silly, but think back to the last project you worked on where a lot of diagrams were created. When you encountered a bug in the application, did you generally turn to diagrams first, or look at the code? XP assumes that most programmers rely on the code, because diagrams do not present enough detail and manually updated diagrams are almost always out of date with respect to the actual code.

Throwing away diagrams does not imply that you throw away the "design." The design itself is embodied in the working code, and can only be thrown away if the code is erased.