Extreme Programming Values - Simplicity

Programmers naturally (and indeed have been taught to) generalize and think beyond current needs to future possibilities, following the rule that it's "better to build it right than to fix it later." This reasoning is based on Boehm's curve for the exponentially increasing costs to repair a bug the later in the development cycle it is found.

Customers, meanwhile, obsess on the features of the system. Building for every contingency goes against XP's economic argument for deferring cost.

XP says, "Build the simplest thing that could possibly work."

XP contends that the money saved by keeping the product as simple as possible outweighs the cost of redesigning and adding features later. Object-oriented methods, used properly, tend to reduce the cost of redesign. The use of design patterns builds in generality without forcing you to handle all cases.

Simplicity and communication work together:

Break the Rules!

In XP, you start by 'breaking all the rules', i.e. duplicating code, not using design patterns, etc. You do this in order to get your current programmer test to pass. Then, you Refactor the code, ensuring that the tests continue to pass. By using Pair Programming, you seek out further refactorings to eliminate duplication throughout the system.

Note that this is a "micro" process, occurring every couple of edits to the code, and not every few hours or days. This allows the programmers to keep moving forward, while also maintaining the cleanest design possible.

By allowing the code to grow in this organic manner, it becomes simpler and more focused on implementing the required functionality rather than being elegant.

For more information about Extreme Programming, visit our Resources page.