Extreme Programming in Theory


Before we go into detail about the dangers of XP, it s worth spending a little time covering the actual XP values, practices, and so forth. As you re reading this book, it s likely that you ve read some of the official XP books. Just in case, though, here s a quick summary of XP.

The Central Premise of XP

The following quote is from XP author Kent Beck:

One of the universal assumptions of software engineering is that the cost of changing a program rises exponentially over time. [2]

This cost of change curve is the primary reason software developers try to get the requirements and the design right as early as possible. XP attempts to turn this on its head, and in fact this turns out to be possibly the single most controversial aspect of XP.

XP s central technical premise is that all its practices work and are effective because the cost of change curve is flattened. The theory goes something like this: Traditionally, the later in a project a change is made, the more costly the change will be. If a process could be put in place that prevents the cost of change from rising over time, then (the theory goes) you could afford to delay big decisions until later.

In effect, if this is true, then (the Extremos believe) you can afford to skip the up-front requirements analysis and design phases, and instead drip-feed the project with new requirements incrementally throughout its lifetime. In theory, XP works because it doesn t cost significantly more to add new features in later than it would to add them in now.

XP is defined by four sets of things: values, practices, activities, and roles. Pretty much all of these are geared toward flattening the cost of change curve.

The Values

The four values in XP are as follows :

  • Communication

  • Simplicity

  • Feedback

  • Courage

Communication

If everyone is in the same room and communicating well, then there s less chance of misunderstandings or but I thought you meant . . . arguments cropping up.

XP takes the stance that the most expressive form of communication is verbal-and that verbal communication is less prone to error and misunderstandings than written communication . Later in the book (trying to keep a straight face), we analyze this approach in more detail.

Simplicity

Simplicity in everything is key: Always try to do the simplest thing that could possibly work. It usually takes less time than, say, doing a complicated thing to achieve the same goal.

It s worth mentioning that even when you follow the simplicity value, absolute simplicity isn t always the best solution. Sometimes a complex problem does require a slightly complex solution. For example, an autopilot on a commercial airliner would work fine with the simplest design, but an airline customer would probably want some extra stuff, such as a backup system, failsafe devices, monitoring software, software that monitors the monitoring software, and so on.

Nonfunctional requirements (such as high availability) all affect the design. So the simplest thing that could possibly work might actually turn out to be quite a complex solution. It s still a good rule of thumb, though.

Feedback

Does this screen really work the way the customer expects it to? Hey, why not ask him ”he s just over there. Feedback in all things is useful and catches misunderstandings early. Often, feedback from others helps to improve your code, your design, your hairstyle, and so on.

Feedback also refers to the way that software design is approached in XP: Build a first-effort prototype of the system (one small part at a time), test it, and adjust the design until it s right. The first version is bound to be slightly off, but it allows you to make a quick start so that you can later fine-tune the design.

In Agile Software Development , Alistair Cockburn recounts a story about Seymour Cray (the famous inventor of various supercomputers) and an early experience he had with using feedback as part of the design process:

Seymour Cray illustrated that a little bit of feedback can replace a lot of analytical work. Of all the published methodologies, Extreme Programming (XP) perhaps puts the most emphasis on feedback, both during design and in the overall project. [3 ]

In addition, the planning game (which we cover shortly) gives feedback to and from the customer, allowing him to steer the project.

Courage

Have the courage to ski off-piste, to base-jump off a ridiculously tall cliff somewhere in Norway, and to make a small design change in your payroll project.

start example

We discuss courage in a bit more detail in the Fear section in Chapter 4.

end example
 

[2] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 21.

[3 ] Alistair Cockburn, Agile Software Development (New York, NY: Addison-Wesley, 2001), p. 66.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net