Four XP Values
One of XP's goals is to make it okay (both culturally and practically) to make changes
at any stage in the project. All modern software processes recognise
that change is an inevitable part of any project: as an understanding
of the customer's requirements improves, new use cases are identified
(or old ones removed); or sudden changes in the business environment
might change the course of the project. In a well designed, highly
modular system, it is possible to take these changes in our stride.
By tracing a proposed change from the requirements down through
the architecture to the low-level design, we can calculate pretty
accurately how much the change will cost. Then the customer can
make an informed decision about whether or not to go ahead with
XP takes this a step further, by attempting to make change a good
thing: to "embrace change".
The cost of change rising exponentially
(Source: Extreme Programming
Explained, Kent Beck)
In the software engineering world, it is widely understood that
the cost of change increases as any project progresses. In the beginning,
few resources have been committed. Later on not only have resources
been expended but the interactions of thousands of decisions have
increased the complexity of making changes. Nevertheless, XPers
claim to have found a way to flatten the Cost of Change curve.
As Kent Beck says in Extreme Programming
"This is one of the premises of XP. It
is the technical premise of XP. If the cost of change rose
slowly over time, you would act completely differently from how
you do under the assumption that costs rise exponentially."
Kent is right when he says that modern tools are helping to reduce
the cost of change. However, the curve is by no means flattened,
and it could be argued that it never will be.
In addition, there is a fundamental aspect of Cost of Change that
Kent appears to have missed. I have been wracking my brains to try
and understand if XP really takes this into account, but I can't
see it. The problem is this:
Once you have written something, no matter how cheaply you did
it, it cost something to write. If you want to change it for something
else, nothing can change the fact that you spent time writing the
code that must now be changed (or even scrapped entirely). Even
if the change is inexpensive, the cost of writing the first version
must still be taken into account. Put another way: you can do
a U-turn in system functionality or design, but not in time.
I think the reason why I have been unable to find a specific answer
to this paradox, is because all of XP is about answering it. Its
four Values are there to try and bring down the cost of making changes.
The four Values are in turn supported by twelve Rules (or thirteen,
depending where you look).
If the combined Values really work, then the cost of making a thousand
changes in direction is offset by the apparent surge in productivity
that we get from: Communication, Simplicity, Feedback and Courage.
XP Value: Communication
XP makes a big issue about its core value of Communication. This
is wonderful, as communication is definitely a key factor to the
success of any project, XP or otherwise.
Unfortunately, XP also makes a big issue about not doing any documentation
(or at least very little, or none at all). I think this is partly
why XP has such a broad appeal amongst earnest young programmers.
After all, documentation really sucks, right? Just like homework
XP Value: Simplicity
XP promotes a throwaway approach to source code (i.e. write, toss,
rewrite). And so, through countless waves of throwaway code, the
design gradually (hopefully) starts to evolve. To counter this time-consuming,
high risk approach, we are encouraged to keep everything simple.
The theory is that if you are constantly re-evaluating where the
project needs to go, then you might lose only a week or two down
any particular design blind alley.
From Extreme Programming Explained
"XP is making a bet. It is betting that
it is better to do a simple thing today and pay a little more
tomorrow to change it if it needs it, than to do a more complicated
thing today that may never be used anyway."
Better still, don't bet! If you have planned, architected and designed
properly, you are much less likely to have to throw any work away.
In fact, the above quote is playing down the amount of rewriting
that takes place. To justify this approach, Kent uses the example
of a general purpose dialog for displaying text. He explains that
a programmer needed to display a message dialog, but decided to
make the dialog multi-purpose "in case anyone else would like
to use it." Two days were then spent writing the "smart
dialog", after which the requirements had changed and it wasn't
needed anyway. This is a fine example, and of course it would have
been much better to simply write a single dialog to display that
one message (probably one line of code). Nobody else had asked for
a multi-purpose dialog, after all. This example is used as the basis
for Kent's Simplicity Value, i.e. only code what you need.
Of course, you don't need to be doing XP to do that. The main difference
is that without XP, you would have a proper design, hence you would
know simply by checking the design whether anyone else was going
to need the same dialog. It's then possible to make a pretty intelligent
decision about whether the time spent coding a "smart dialog"
is justified. With XP, you just can't do that because tomorrow's
design doesn't exist yet. You're still coding it.
Component re-use is a wonderful thing. Spurious re-usability "just
in case" is a waste of time. So if we know that we are going
to be programming precisely to a design, coding up the requirements
and nothing more, then why do we need XP's Simplicity Value?
To be fair, this Value is a useful one, in the sense that it makes
the programmer slam on the brakes before they write something they
don't need to. It's common sense to keep everything as simple as
possible, i.e. never over-engineer. A common example is to produce
a "framework" due to some unknown, hypothetical future
requirement. If the requirement isn't there now, don't code for
It is, however, possible to take this rule too far. XP uses constant
refactoring to "shape" the design as you go along. In
other words, you don't just code to the requirements (and nothing
but the requirements), you take a much more myopic approach, and
code to just the piece of code that you are working on right now.
Later, even during the same project iteration, maybe even the following
day, when you need to write something else that must interface with
the same piece of code, or re-use it in some other way, you need
to rewrite it. The old piece of code is simply thrown away. The
day or two that was spent writing it is wasted.
I would suggest the following reworked version of the XP Simplicity
Value for non-XP projects:
1. Design only what is in the requirements. Anything extra is
unpaid work, and you probably won't receive any thanks from the
customer when the project is delayed due to a bonus feature that
they didn't even ask for. QA won't be too pleased either. Don't
write a framework for the future (unless the requirements ask
for it). If it's in the requirements, question it and suggest
that it be removed. Chances are that by next year there'll be
a Java API that does what your framework-in-waiting does anyway.
2. Program only what is in the design.
3. (For QA) - Test only what is in the requirements. If you see
anything extra, reject it and demand its instant removal from
At first glance this is not that different to XP's approach. However,
XP takes things a lot further by also applying the YAGNI (You Ain't
Gonna Need It) mantra to its design philosophy. This process is
described in (among other places) Chapter 26 of Extreme
Programming Explored. The result (as described above) is
that in XP you end up writing code which you know is going
to be rewritten later.
XP Value: Feedback
XP values feedback as a way of determining the current state of
the system. For example (from Extreme Programming
Explained, regarding scoping of user stories):
"The business people say, "I had
no idea that was so expensive. Just do this one third of it. That
will do fine for now."
This is a remarkably naive, idealistic approach. The problem with
the above example is that business people generally do not react
reasonably to comments such as "That's too difficult."
They want something specific done by a certain date.
Customer negotiation is a tricky business, and is not limited to
XP projects. The difference with XP is that customer negotiation
is arranged so that it runs throughout the project, and is fundamental
to the way the process works at every stage. Due to the nature of
XP's contracts, contract negotiation effectively takes place every
time a programmer talks to the on-site customer.
I would suggest that your programmers are probably not the best
people to handle the finer points of customer negotiations. On the
other hand, programmers are, for the most part, very good at programming.
In XP Explained, Kent also tells
us that: "Optimism is an occupational
hazard of programming. Feedback is the treatment."
This is surprising given the patently optimistic, idealistic nature
Feedback also involves "early production", i.e. getting
an early iteration of the project into the customer's hands as soon
as possible, and then frequently feeding the customer new product
updates (every one to three weeks) as development progresses. This
provides valuable feedback from customer to programmer.
Apparently most projects have the opposite strategy. In describing
"most projects", Kent postulates:
"The thinking seems to go, 'As soon as
the system is in production, you can no longer make 'interesting'
changes, so keep the system in development as long as possible.'
What projects are these exactly? I've never encountered a project
where the customer (or the production team) wanted it to take as
long as possible. Perhaps they're talking about C3...
Of course, early feedback is an essential part of the project mix.
Releasing actual production builds once a week is a bit over the
top though. You can receive useful feedback from the customer without
going through this time-consuming rigmarole of production releases
(for more thoughts on this, see my article Fear
XP Value: Courage
Everybody could do with a good dose of courage every now and again.
Of course, courage as described in XP is not the same as, say, storming
an embassy full of armed terrorists. That's an inherently scary
thing to do, even in a game of Counterstrike. I would imagine that
the real thing would be pant-wettingly scary.
Nevertheless, to perform XP, you need courage.
In all seriousness, I think there is something very right in this
particular Value. Kent describes an example project in which an
architecture was discovered to be flawed, and fixing one defect
caused another one. The team was right to fix the architectural
flaw, which took several days of concentrated effort.
Another example of Kent's does make me slightly uneasy, however:
he talks about throwing code away. He suggests that if the end of
the day is coming and the code is "a little out of control",
it should be scrapped.
This is also described by William Wake in Extreme
Programming Explored, as "going home clean". He
"Go home at 5PM... Notice that nothing
is hanging over your head: everything you've done for the day
is integrated or tossed."
At first I couldn't quite put my finger on what it was that made
this suggestion seem so wrong. On the surface, it seems like a nice
and courageous attitude: if the code is wrong, just "toss it"
and start from scratch the next day. One day of wasted coding isn't
going to matter, after all (although add it to the 300 other wasted
days, and it begins to feel very courageous. Now multiply those
301 days by 8, if you have a team of 8 programmers, and suddenly
you realise your XP project is positively overflowing with
Then the actual problem hit me. It's actually a general problem
with XP, and its "throwaway" approach to production code.
The programmers are encouraged to write with an attitude of "I'll
just start coding and see what happens." If they end up writing
garbage, it doesn't matter because they can just throw it away,
go home clean, and start again tomorrow. Same goes for the design.
Let it evolve, and see where it goes. The collective consciousness
of the XP team will nudge the so-called design to some place or
other. When it's there, if it's wrong then we'll just collectively
nudge it somewhere else.
To quote Kent again:
"Maybe you have three design alternatives.
So, code a day's worth of each alternative, just to see how they
feel. Toss the code and start over on the most promising design."
This approach is also central to XP's concept of an evolving 'design'.
So, it is possible (and common) to go down some long term design
blind alleys. It's possible because you are required to take a myopic
view of what you are creating, and to only code for one piece of
functionality at a time. Don't you dare think ahead, boy! As a result,
Kent's "three design alternatives" might unknowingly be
played out over a much longer term than a few days. They won't be
planned for, because each design would have been assumed to be the
Wouldn't it be easier, and kinder to the soul, to just concentrate
on getting it right first time? It is possible, and (like XP's rules)
is an acquired skill. You just need to be good at what you do, as
with any skilled vocation. You need some aptitude and imagination.
You don't have to create something to know whether it is going to
work or not. Just think ahead, factor in as much as you can without
losing sight of your goal.
It can be done. In fact many programmers and designers do this
regularly. So, just what is it that XP is trying so hard to fix?
>>And Finally, the Conclusion
Reality XP Forum
Back to XP Central