Extreme Programmers recommend that we Do The Simplest Thing That Could Possibly Work. The idea is that simple code means you're travelling light -- low up-front investment, and not much to slow you down when you want to change.
What Is Simplest though? Is it "the first thing that comes to mind"? Is it "whatever takes the least effort"? "Whatever takes the least mental strain"? Well, here's the official scoop:
www.zeroplayer.com
The Four Commandments:
Simple code:
Passes all the tests.
Expresses every idea that we need to express.
Says everything Once And Only Once.
Has no superfluous parts.
Wiki pages for each of the above, respectively:
Alternative list:
Runs all the tests.
Maximizes Cohesion
Minimizes Coupling
Says everything Once And Only Once.
Alan Shalloway and Ron Jeffries agreed on a slightly more constructive pronunciation of the four rules for emerging simple design:
Runs all the tests.
Contains no duplication (Once And Only Once)
Expresses all the ideas you want to express.
Do not put the implementation of unrelated ideas in the same method.
Classes should organize ideas in a readily understandable way.
Use appropriate names so you don't have to explain method, member or class names with additional documentation
Methods and classes should be implemented so they can be understood totally from their public interfaces. This not only allows for up-front testing, but decreases coupling.
Minimizes classes and methods. This is actually redundant, but is a reminder that we are trying to make this simple and concise.
The way I like to derive this is to think about what is most important. The most important thing is that the code works. We use tests to show us that the code works therefore the first point must be that all the tests must run. The next most important thing is that the code is as easy to understand as possible, therefore we need to ensure that it expresses every idea that we need to express clearly. Even though it works and it's understandable, we still need to consider maintainability. Therefore say everything once and only once and minimize the number of classes and methods. -- Jason Yip
Along similar lines, here is some discussion that was originally on Once And Only Once:
I agree with Wayne Carson that Once And Only Once needs some constraint - or more explanation. I have seen this principle used to justify way too much inheritance for implementation (i.e., code sharing), which often limits reuse. Using Design Patterns terminology, I'd rather see Once And Only Once operate at the interface level, where it leads to a nicely factored set of interfaces, and encourages interface inheritance (in which case delegation can be used to reuse implementation). But expressing this rule simply in terms of raw code can be counterproductive.
-- Joe Bowbeer
In XP, the constraint is Simple Design... too much inheritance implies too many classes, so perhaps you want refactor to combine classes, and then possibly refactor again to use composition instead of inheritance.
Later on in the Once And Only Once page, the following paradoxical discussion took place:
I think the application of Once And Only Once to code should be restricted to not making the overall system too confusing or tightly coupled. Over reuse can make the system difficult to modify. Think of the extreme case of code produced by an efficient optimizing compiler. -- Wayne Carson
My experience is quite the opposite. If I apply the once and only once rule to code until I can't any more, I certainly get lots of little pieces. This takes commitment. If I am committed to communicating through my code (System Of Names, etc), though, the result is not confusing. And it certainly isn't tightly coupled. It is radically decoupled, in that changes tend to be very localized, and all without much in the way of planning.
I can see this happening, if *I* (or apparently Kent) does lots of refactoring, the result will be radically decoupled code. The nagging problem I have always had with XP is that I could not find which bit of XP said that we would end up with radically decoupled code. Once And Only Once kind of means that we will, but the once can wind up splattered all over the place and still be only once. If there was also an All_in_one_place XP/wiki word I would feel way more confident in what the XP protagonists are saying. I expect the XP people will say of course, but it has been my sad experience that what it is about code that smells is not obvious to all programmers. I could do an XP project and *know* the project would come out on time and on budget, just so long the team first agrees that one thing we are going to need that will never appear on any user story is Radically Decoupled Code.
Does anyone find that there is a learning tradeoff between systems that have lots of little pieces and those with fewer pieces? It seems that the chunkier systems might be easier to understand at first glance.
Yes, and cards and diagrams help, but when it comes down to actually doing things the highly-factored system is easier to modify by far. It's much easier to get to some specific thing you do need because the highly-factored system separates out all the information you don't need.
-- Ron Jeffries
A related idea in the business domain: "Strategy as Simple Rules", an article
in Harvard Business Review (January? '01), online for a fee at www.hbsp.harvard.edu 
-- Bill Wake
I don't know, I find it funny that they say "the success of ..., Enron ... " :) --Vlad Ender
The question What Is Simplicity is closely related to the What Is Quality question.
Am I the only one that finds this list funny: "Once And Only Once, Dont Repeat Yourself, Redundancy Is Inertia, ..."?
No. That is, indeed, quite hilarious. Maybe a reflection on the fact that Wiki doesn't exactly encourage XP? Or, that we're not refactoring the Wiki mercilessly.
'Au contraire. i believe it's the only rule worth repeating. repeatedly.' similar to 'The beatings shall continue until morale improves'
According to Worse Is Better there is a tradeoff (or at least a tension) between simplicity of interface and simplicity of implementation? If an XP team must make a choice which one does it choose? -- Asim Jalis
An XP team does not make that choice up front. Write a test, make it pass, refactor, repeat. Refactor to the point of simplicity. Listen to the code.
See original on c2.com