Extreme Programming System

ExtremeProgramming system is a discipline of software development based on values of Simplicity, Communication, Feedback, and Aggressiveness.

ExtremeProgramming is expressed as a system of practices which balance each other to help keep projects on track.

Delegating priority setting to the customer, if done blindly, could lead to a choice of features, and an order of those features, that might leave some key product capability too late. If the system is supposed to be a distributed database, but the priorities didn't call for any work on distribution until the last week, something bad might happen.

To balance priority-setting, XP has the rule WorstThingsFirst. This rule means that the entire team will consider and discuss the risks of the project. During this discussion, the team reaches agreement on risky areas, and defines efforts (think Technical Stories, though we don't use that term) that should be undertaken to reduce the risks.

To accommodate learning and discovery of new risks or opportunities, XP has the practice of doing a ReleasePlan, an overview of the entire remaining development period, every few iterations. This provides a chance to surface new risks, bring forward capabilities that would add more value than the ones formerly contemplated, and to tune the plan in any other agreed way.

Within this context, the practice remains solid that the customer sets the final priorities. The developers inform the customer of the risks, recommend what is to be done, and do what comes out. (I suppose that a really stupid customer might say "don't worry about performance". I suppose that a developer who seriously thought that was wrong should consider resigning. In practice, customers are almost always smart enough to see risks.)

Once the ReleasePlan is in place, we do IterationPlanning. The customers select the UserStories to be worked on, developers determine the EngineeringTasks to implement the stories, sign up, and estimate how long it'll take. We put into the iteration the amount of work we can do.

During development, we may think of some class or method that would be useful later. XP has a rule, called YouArentGonnaNeedIt. That rule says that we never implement that speculative class or method. We have that rule, and we state it so firmly, and we live by it so carefully because to do otherwise would be to violate the balance between customer setting priorities and developer estimating time.

We have other rules during development. For example, we always DoTheSimplestThingThatCouldPossiblyWork. That is, we choose the simplest approach to solving the problem, subject only to the proviso that it could work. We do that because it minimizes the cost of doing whatever we're doing.

There are risks with the Simplest rule, mostly to the effect that the simplest thing might not hold up, and it might be hard to fix it later. These risks are balanced by some facts, and by some other XP practices. The facts relate to the characteristic of well-factored objects that they encapsulate behavior in a single place. Thus, when the behavior needs to be optimized or enhanced, there tends to be only one place to fix, making it not that difficult to fix. There is also the risk that the code might not be encapsulated, that by doing the simplest thing the system was left with redundant or ugly code. We balance that by our rule RefactorMercilessly, which ensures that the objects are clean and that there is no duplication that gets in the way.

I could, and in the fullness of time, will go on. The overall picture is that the XP practices have been defined to balance the forces acting on the project.

XP is one prescription for a software process. There are many such prescriptions out there, and there are many other ad-hoc processes in place that people actually use. Development projects are free to choose whatever process makes sense to them.

XP has one other rule: TheyreJustRules. This is not license to break the rules: it is license to come together as a group and change the rules. If an XP team found that some rule, say YAGNI, didn't properly balance the project, they would change the rule, add one, or remove one, to bring the project into balance. The ExtremeProgramming folks have worked for years to refine these practices, and we are confident that they are very close. But we continue to watch them in use and adjust if and when we actually need adjustment.

We offer XP as one approach to consider, and we offer the rationale behind it to aid interested people in deciding whether XP applies to their situation. We are not saying it's the only way, we are not saying anything bad about any other way. We are saying XP works, it's consistent, it's lightweight, it's fun, it's worth considering.

-- RonJeffries

In a word: Outstanding! I like the above description enormously. It is (IMHO of course) clear and concise, with a confident yet honest and unpretentious tone. Keep this up and I might just have to retract all my previous complaints about the perceived tone/exclusivity in the descriptions of other XP practices. Nice work Ron! Thanks for being persistent. -- BradAppleton

Discussion moved to ExtremeDatabaseProjects.

I blundered across XP some time ago - 18 months - before XP was "cool". This site is what I began to read having no idea what I was getting into. When I hit the VoodooChickenCoding section, I laughed so hard that I had tears rolling down my cheeks. Then, I began to cry, because I've seen it and lived it. I guess we've all been there. For the past 18 months I've evangelized the concepts. I'm in an IT/DP shop now. Starting my first major project which appears to be solo. My first task was to ask the customer - Operations - what they really wanted the software to do. They looked at me like I had three eyes and a horn. I keep telling them, "You're the customer, you tell me what you need." I still get the stare. I don't think they believe me.

So, the new project will introduce Oracle into the product. QC has a fit (they're challenged as it is). I point out that I didn't see what the big deal was, that the code would come with unit and functional tests / test rigs. We're now staffing a new QC department - they all had cardiac arrest ;) Apparently, throw it over the wall to QC is the standard s/w delivery method.

See, XP just feels right. I've worked in all manner of places over the past 20 years. I've yet to see one project (and not only the ones I've been on) to come in on time and on budget. Period. XP resonates with me as addressing what has been done wrong. I'm off to conquer the world. -- CharlesGilley?