The Four XP Values

<< XP's Audience

Embracing Change

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 the change.

XP takes this a step further, by attempting to make change a good thing: to "embrace change".

The cost of change rising exponentially over time (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 Explained:

"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 always sucked.

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

"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.

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 the software.

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 of XP.

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 of Non-Progress).

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

"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 courage).

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 right one.

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

Software Reality XP Forum

<< Back to XP Central

<< Back to Lifecycle