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:
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
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.
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.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006