ExtremeProgrammer''''''s recommend that we DoTheSimplestThingThatCouldPossiblyWork.  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.

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

	: '''The Four Commandments''': http://www.zeroplayer.com/images/stuff/TheFourCommandments.png

Simple code:
	1. Passes all the tests.
	2. Expresses every idea that we need to express.
	3. Says everything OnceAndOnlyOnce.
	4. Has no superfluous parts.

Wiki pages for each of the above, respectively:
	1. UnitTestsTellYouWhenYoureDone, ...
	1. SelfDocumentingCode, ...
	1. OnceAndOnlyOnce, DontRepeatYourself, RedundancyIsInertia, ...
	1. YouArentGonnaNeedIt, MinimumNumberOfClassesAndMethods, ...

Alternative list:
	1. Runs all the tests.
	1. Maximizes Cohesion
	1. Minimizes Coupling
	1. Says everything OnceAndOnlyOnce.

----
AlanShalloway and RonJeffries agreed on a slightly more ''constructive'' pronunciation of the four rules for emerging simple design:
	1. Runs all the tests.
	1. Contains no duplication (OnceAndOnlyOnce)
	1. 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.
	4. 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. -- JasonYip

''Along similar lines, here is some discussion that was originally on OnceAndOnlyOnce:''

I agree with WayneCarson that OnceAndOnlyOnce 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 DesignPatterns terminology, I'd rather see OnceAndOnlyOnce 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. 
-- JoeBowbeer

In XP, the constraint is SimpleDesign... 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 OnceAndOnlyOnce page, the following paradoxical discussion took place:''

I think the application of OnceAndOnlyOnce 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. -- WayneCarson
 
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 (SystemOfNames, 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.
--KentBeck

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. OnceAndOnlyOnce 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 RadicallyDecoupledCode. 
-- AlanChristiansen

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

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

A related idea in the business domain: "Strategy as Simple Rules", an article
in Harvard Business Review (January? '01), online for a fee at http://www.hbsp.harvard.edu/hbsp/prod_detail.asp?R0101G
-- BillWake

I don't know, I find it funny that they say "the success of ..., Enron ... " :) --VladEnder

----
The question WhatIsSimplicity is closely related to the WhatIsQuality question.

----
Am I the only one that finds this list funny:  "OnceAndOnlyOnce, DontRepeatYourself, RedundancyIsInertia, ..."?

''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 WorseIsBetter 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? -- AsimJalis

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

----
CategoryExtremeProgramming CategorySimplicity