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 itall 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:

Draw a diagram.

Write a unit test.

Write some code.

Repeat steps 2-3 until the feature is complete.

Throw away the diagram.

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.