dothesimplestthingthatcouldpossiblywork.html

极限编程 Extream Programing

<p>
Now I am eager to do two things: reread several Wiki topics from a new perspective, and write some code!
--<a href="http://c2.com/cgi/wiki?KielHodges">KielHodges</a>
<hr>
It occurred to me that DTSTTCPW has a near relative, <a href="http://c2.com/cgi/wiki?SimplifyTheRequirements">SimplifyTheRequirements</a>.  Of course, once you have simplified the requirements, then you can still DTSTTCPW.  However, you might not think to simplify the requirements - most people don't explore the dimensions of negotiation in them.  --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<hr>
A couple of other pages (references, anyone?) mention the possibility that one should sometimes refactor the existing code <em>before</em> attempting to <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> (although without giving much/any rationale).  Furthermore, the <a href="http://c2.com/cgi/wiki?OpenClosedPrinciple">OpenClosedPrinciple</a> urges us to build systems that can be extended without change to existing parts.  So here's a somewhat more extreme take on 'simplest':
<p>
You are coding a <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>, and that means you are adding new functionality to an existing system or adding variants to existing functionality.  <strong>Therefore</strong> perform the following steps:
<p>
<PRE>
    1. Refactor the system until the new functionality can be accommodated solely by adding new methods and/or classes
    2. Add the new functionality
    3. Refactor the resulting system again, to remove duplicates and to simplify the added code.
<p>
</PRE>
This is probably too extreme to be always feasible.  But is it a goal worth striving for?
<p>
<em>This reviewer thinks not. To do step one requires that you have an implementation clearly enough in mind to drive a refactoring. That's generally too much thinking. Better to implement directly, with if statements or whatever, and then refactor.</em>
<p>
<em>Refactoring first should be done, however, if the code isn't clean when you start, i.e. if the last person passing through didn't get all the way to simple code. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
Note that the third and subsequent times through, you won't have to modify the if statements, because they will have been turned into polymorphism the second time (either before or after implementation). SecondTimePaysForFlexibility<a href="http://c2.com/cgi/wiki?edit=SecondTimePaysForFlexibility">?</a>.
<p>
If you can see how to make it clean before you do it, make it clean. If you can't see how to make it clean, do it anyway. If you can't see how to do it, take a walk. --<a href="KentBeck.html">KentBeck</a>
<hr>
<p>
Can we use <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> outside of <em>Software Engineering</em>?
<p>
Reply: YES!  See <a href="http://c2.com/cgi/wiki?DoTheBestYouCan">DoTheBestYouCan</a>
<hr>
Outside Software Engineering?    How about Asimov's &quot;M N C&quot; = Minimum Necessary Change?    From the &quot;End of Eternity&quot;.
<p>
<a href="http://c2.com/cgi/wiki?DickBotting">DickBotting</a>
<hr>
I think DTSTTCPW and XP look like a <a href="http://c2.com/cgi/wiki?TetrisAnalogy">TetrisAnalogy</a>
--<a href="http://c2.com/cgi/wiki?FrancisTownsend">FrancisTownsend</a>
<p>
Good analogy, thanks, <a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>
<hr>
<p>
Doesn't <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> result in interfaces that keep changing?  In my experience changing the implementation generally doesn't cause nearly as much pain during refactoring as does changing the interface.  
<p>
<em>Yes, the interfaces keep changing. That's good, it means you are learning. Naturally, if the interfaces are </em>
<strong>external</strong>
<em>, you need to consider whether changing them is still of low enough cost to afford to change. There is a tradeoff. We suggest that it isn't where many people assume it to be.  --rj</em>
<p>
What if you were to say design the interface to support your known requirements and implement in the simplest way for your current task?
<p>
What I'm worried about I guess is that <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> could result in a system that is architecturally simplistic.
<p>
<em>It will certainly result in a system that is architecturally </em>
<strong>simple</strong>
<em>: just complex enough to support the current functionality. In what way might that be bad? When is a simple architecture simplistic? --rj</em>
<p>
Hrrmm, thanks for the comments.  This concept has been churning in my mind for a number of days.  I can definately see advantages with minimizing the risk of over-engineering the code.  The subsystem builder in me is a little bothered however. :-)  What I'd be concerned about is that by concentrating on the simplest thing possible you might be painting yourself in a corner.  I am having trouble coming up with a good example however.  I think the word simplest is bringing up the wrong connotations in my mind.  I'm equating simplest with quickest which I don't think is what this is about.  Perhaps a better way of saying this is &quot;implement the simplest architecture that could possibly work&quot;.
<p>
--<a href="http://c2.com/cgi/wiki?GlenStampoultzis">GlenStampoultzis</a>
<p>
We're saying more than that, or less. We're saying consider all solutions to your task that could possibly work. Implement the simplest solution. Refactor from there if and when needed.
<p>
We're saying that if you build your objects properly (i.e. in standard OO modular high-cohesion low-connection fashion), you won't ever paint yourself into a corner.
<p>
And we're saying that when you do enhance the simple solution (and you generally will), you will always wind up wtih a system that is just right for what it does so far.
<p>
And we're saying that that is just where you want to be. Everything just right, nothing added that isn't needed.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<em>Okay, I can see this is something I'll have to try for myself on a future project to see how it feels.  One question: Is this idea incompatible with concepts such as layered architectures? For example: <a href="http://c2.com/cgi/wiki?FourLayerArchitecture">FourLayerArchitecture</a>?</em>
<p>
<hr>
<p>
I am working on a systems integration project that has gotten itself into what I call a SpaghettiArchitecture<a href="http://c2.com/cgi/wiki?edit=SpaghettiArchitecture">?</a> -- a bunch of (generally small) programs that connect one database to another, or one app to another, and so on. This has been a result of <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. &quot;Well, we need to get <em>this</em> data over <em>there</em>.&quot; &quot;Oh, just write a little batch transfer program.&quot; The result rapidly becomes an unmaintainable mess -- everything depends on everything else, the business logic is scattered, and there's not even a single codebase to <a href="RefactorMercilessly.html">RefactorMercilessly</a>.
<p>
So perhaps we can say that <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> is a reasonable approach <em>within a single program or codebase</em> (provided, of course, that we <a href="RefactorMercilessly.html">RefactorMercilessly</a> and <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> to keep it from becoming <a href="http://c2.com/cgi/wiki?FlimsyAndBarelyFunctional">FlimsyAndBarelyFunctional</a>). But on an architectural level, it is absolutely necessary to do  a <a href="BigDesignUpFront.html">BigDesignUpFront</a> (or at least a SmallDesignUpFront<a href="http://c2.com/cgi/wiki?edit=SmallDesignUpFront">?</a>) -- put the right architectural components in place, plan for future expansion, decide how we're going to let our different apps and programs be loosely coupled, and so on. 
<p>
Thoughts?  -- <a href="http://c2.com/cgi/wiki?RobertEikel">RobertEikel</a>
<p>
<hr>
This doesn't sound like <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> at all to me. It sounds a lot more like DoTheQuickestThingThatMightWorkForAWhile. Programs were simply plugged in without any particular thought to the overall picture. I've never read or heard of anything in XP that says this is a good idea.
<p>
The simplest thing definitely includes the <em>Architecture</em> as well as the <em>Code</em>. In fact, one of the first steps in heading down the XP path on a project is choosing a metaphor for the overall system. Whether the metaphor is an assembly line or a power distribution grid or a bulletin board or whatever, it gives an overall shape to the various code parcels (programs) in the system. 
Yes, this is architecture design. It's also upFront. But, it should also be <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. Don't choose a system metaphor that is more complex than required. Yet, this leads me to a question. Does <a href="RefactorMercilessly.html">RefactorMercilessly</a> apply to the architecture/metaphor as well? It might need to, because over the 5 or 10 or 20 years of lifetime of a system, the needs of the system can change enough that the metaphor no longer serves well.
--<a href="http://c2.com/cgi/wiki?DougSwartz">DougSwartz</a>
<p>
Regarding <em>Programs were simply plugged in without any particular thought to the overall picture.</em>  My reading is that that is exactly is meant by <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>, and it is the exact recommendation of XP.  However, ... XP contains two pieces, a predecessor and a successor step: First, <a href="RefactorMercilessly.html">RefactorMercilessly</a>, until the system is in its simplest, tidiest, neatest form.  Then <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>, then, <a href="RefactorMercilessly.html">RefactorMercilessly</a> again, until the system is in its overall simplest, tidiest, neatest form.  Doing <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> without doing <a href="RefactorMercilessly.html">RefactorMercilessly</a> gets the results Robert describes, not XP results.  This is my reading of XP. --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>
I think Alistair is right on the money. Individual practices, taken alone, is not where XP gains its strength.  It is the support each of the practices imparts on the others that make it viable.  Robert even alluded to it in his statement, <em>?<a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> is a reasonable approach ? provided, of course, that we <a href="RefactorMercilessly.html">RefactorMercilessly</a> and <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a></em>  (I took out the part about single code base because I don't believe that's a constraint on using XP practices).  So, the first time the <em>little batch transfer program</em> needed to be written, that one off solution might have been the simplest thing without much need for refactoring, etc.  Maybe even the second time another one-off solution was best (maybe not).  But when you start talking three or more times of doing this, you need to step back and start looking at the whole and start refactoring to get to a better solution.  And, of course, since you have the unit tests, you can change things without worrying about breaking the system.  So at one point <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> was employed correctly, but some time after, the other supporting practices were not used to make sure that the solution remained that way.  --<a href="http://c2.com/cgi/wiki?TomKubit">TomKubit</a>
<hr>
<p>
My take on this:
<p>
You have a task to do today (probably from a <a href="http://c2.com/cgi/wiki?TaskCard">TaskCard</a>).  As a good programmer, you can probably think of at least 3 (and possibly a dozen) different ways to carry out the task.  Pick the simplest one that could possibly work. -- <a href="http://c2.com/cgi/wiki?JohnBrewer">JohnBrewer</a>
<p>
<hr>
See also <a href="http://c2.com/cgi/wiki?ThreeBearsProgramming">ThreeBearsProgramming</a>
<p>
<hr>
<p>
See <a href="http://c2.com/cgi/wiki?ManagingEvolutionaryDesign">ManagingEvolutionaryDesign</a> and <a href="http://c2.com/cgi/wiki?EvolutionaryArchitecture">EvolutionaryArchitecture</a>
<p>
<em>I moved Bryan's excellent questions to the above pages, since they seemed to me to be tangential to the main point of this page. Someone else put the questions back in-line. I just took them out again. Let's discuss this on <a href="http://c2.com/cgi/wiki?QuestionsMakeGoodPages">QuestionsMakeGoodPages</a> rather than thrash. --<a href="KentBeck.html">KentBeck</a></em>
<p>
---
A little bit philosophy  about , what I would call,  MozartPrincipe<a href="http://c2.com/cgi/wiki?edit=MozartPrincipe">?</a>. My colleague  Dr. Meinhold once said that good code is like Mozart symphony . If you add a single note or you take a single note , harmony is destroyed.  If  you add single line of code or you take a single line of code, good code will  break. 
There are a lot of examples where good code in hands of not skilled or not trained or not  experienced programmers , turns in shortest time into chaos. Bad code never turns so quickly into such chaos. This instability of good code comes from &quot;higher energy&quot; level. We can say that good code is like a ball on top of the hill and bad code is like a ball in valley.  But because of &quot;higher energy&quot; level good code can evolve easily and rapidly ( &quot;maintenance&quot;, &quot;extensibility&quot;, &quot;expandability&quot; , &quot;can grow in not predictable directions&quot;)
Good code is balancing on thin line between chaos and order  where very small change can either bring chaos or higher degree of order. Or simple to say it is like fire : Could be good servant and bad master. 
<p>
--- SusaGoran<a href="http://c2.com/cgi/wiki?edit=SusaGoran">?</a>@excite.com
<p>
I've got to disagree with you on that one.  Good code is robust, and will stand up to a goodly amount of abuse before failing.  Bad code is brittle to start out with, and the slightest perturbation will cause it to collapse.  --<a href="http://c2.com/cgi/wiki?JohnBrewer">JohnBrewer</a>
<p>
---
<p>
<em>Doesn't <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> result in interfaces that keep changing?  </em>
<p>
Probably, but this happens anyway, unless everyone always designs the interface correctly first (and this usually doesn't happen.) 
<p>
--- <a href="http://c2.com/cgi/wiki?DavidOtoole">DavidOtoole</a> 
<p>
OTH, the most visible interfaces will probably grow to a reasonable state fairly quickly. Sure, you won't get it right the first time, and probably not the second time. If you haven't got it right by about the 10th time you've refactored the interface that month, you've probably got problems. (Bearing in mind that an addition to an interface is a lot easier than a wholescale refactor, but enough of them give you cruft). The key, of course, is to be able to quickly locate the areas your refactoring breaks so that you can fix it quickly. Anyway, the point is that your major public interfaces will eventually stablise (provide you stick to <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>), and you can save major changes to when you do your major refactors.
<p>
--- <a href="http://c2.com/cgi/wiki?RobertWatkins">RobertWatkins</a>
<p>
<hr>