xpisapseudomethodology.html

极限编程 Extream Programing

<em>Also as <a href="http://c2.com/cgi/wiki?BuckarooBanzai">BuckarooBanzai</a> says: &quot;No, no, no, no.  Don't tug on that.  You never know what it might be attached to.&quot;</em>
<hr>
&quot;no one has contradicted my assertion that this is just a codification of bad programming practices bad environments.&quot;
<p>
I contradict it.  You haven't given any argument for this.  I assumed when
you said it that you were just in a bad mood.  
<p>
You seem to be complaining about two kinds of complexity.  One is that
the XP guys keep adding more and more material to their description of
XP.  I have no problem with them doing this.  They have a process that they
like and are trying to explain it to us.  It will probably take them
several years to figure out how to explain it.  Their final description
might be quite different from the original one.  That is the nature of
describing nontrivial things.  We are watching a work in progress, and
it will be messy.
<p>
The second kind of complexity is more interesting to me.  Suppose that
a problem requires a certain kind of solution to achieve our ends.  We
don't know what it is; that is what makes software development interesting.
Instead of going off and studying the field, we start making our tests run.
We try to <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>, except that it won't work.
We make an honest mistake; it seemed to us that it might possibly work.
We pick epicyles when we really should have made everything rotate
around the sun.  Each test case then requires a lot of adjustments to the
system to make it work.  Every so often we wonder whether there isn't a
simpler way to get the job done, but we can't see one, so we go back to work.
<p>
I've been in a situation like this.  I was adding optimizations to a compiler
when this happened. However, I found some nice papers that described some 
theory that we could use, so we restructured the compiler to use the 
theory.  Because the compiler was fairly well factored, it
wasn't all that bad to change it to use the new theory.  We switched
from the equivalent of epicyles to newtonian mechanics and were happy.
<p>
It seems to me that this could happen on an XP project.  One of the 
developers comes to work one day and says &quot;You know that problem we've
been having?  I think we are going about it all wrong, and we should
really address it like this.&quot;  The team will probably stop for a bit,
a few people will go off and do some experiments and then some major
refactoring and replacement might take place.  This is not something
that the XP folks talk about, but it seems common sense to me.
<p>
XP is designed for situations that have lots of fairly shallow problems.
Paying one person is not hard.  Paying fifty thousand people is a lot
harder.  However, the problem is not understanding some deep underlying
theory, but rather in keeping from being overwhelmed by details, and making
sure that you can keep changing the system as the rules change. You could
write fifty thousand nice simple payroll systems, one for each person,
but then it would be a nightmare to change them whenever the rules changed.
<p>
If you are working in an area with a lot of deep theory (<a href="http://c2.com/cgi/wiki?OptimizingCompilers">OptimizingCompilers</a>,
for example) then XP needs to be modified, at the very least.  YAGTNI assumes
that you know the theory, and that you use it to tell whether you are going
to need it.  &quot;The simplest thing that could possibly work&quot; depends on your
experience; what a novice thinks might work, an expert knows will not.  An
expert compiler writer will start with a scanner, parser, symbol table, and
code generator, even though this is not needed for the first test cases.
Perhaps this is what the XP folks mean by picking a metaphor.  Maybe what
you learn in a compiler course is the &quot;compiler metaphor&quot;.
<p>
Anyway, I agree that XP might lead you down the garden path for awhile.
This is less likely when building business systems, which are broad and
shallow rather than narrow and deep, and where there is not much published
theory that is useful to software designers.  Also, if you have factored your
software well then you can rewrite it to fix the problem when it is discovered.
Finally, if you have enough experience to know the right path, then I
don't see why XP is going to prevent you from going where you know you
should go, and if you don't have enough experience to know the right path,
a different methodology will not necessarily ensure you find it.  Once you
realize you are wrong, it should be easier to get on the right path if you
are using XP.  The main downside I can see with XP is that if you had been
doing more upfront research, maybe you would have discovered that there
was a right path (by reading a book on the subject, or hiring a consultant)
and could have saved a lot of wandering in the dark.  
<p>
-<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a>
<hr>
Thanks, Ralph. Excellent as always.
<p>
As for expertise and knowledge, we're all for it. YAGNI and Simplest are warnings NOT to use one's expertise until it is really called for. Kent refers to digging deep into one's bag of tricks to solve a problem. We try to stay at the top of the bag all the time.
<p>
A wise consultant (I know some) uses his knowledge to keep the system simple, rather than dragging it all out and stuffing it into the code. That's what YAGNI is really all about.  --<a href="RonJeffries.html">RonJeffries</a>
<hr>
I'm not sure why XP needs to be modified for deep theory work, though I wouldn't mind hearing how it might be done.  With regard to Ralph's compiler example, I agree that you'd start with some pretty powerful tools even for the first few test cases, but I think this is because you (as a compiler guy) know that this is indeed the simplest thing that could possibly work.  And though you might employ a scanner generator and a compiler compiler for a complex language problem, you probably wouldn't try to write the entire grammar in one go.  Just a few productions, for a start.  Just enough to make your first test case run clean.
<p>
--<a href="http://c2.com/cgi/wiki?RobMee">RobMee</a>
<p>
<hr>
We have successfully incorporated a type of design documentation with our XP practices, which is the simplest design documentation that could possibly work for us, <a href="http://c2.com/cgi/wiki?InstanceDiagram">InstanceDiagram</a>.  We also use an <a href="http://c2.com/cgi/wiki?InstanceDiagram">InstanceDiagram</a> to show the instances/objects which are created through execution of the <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> suites.  Take a look to see how we can easily depict our system (and proposed design changes to our system) on <a href="http://c2.com/cgi/wiki?OnePieceOfPaper">OnePieceOfPaper</a>. We have found that using an <a href="http://c2.com/cgi/wiki?InstanceDiagram">InstanceDiagram</a> in conjunction with user stories, i.e. use cases, <a href="http://c2.com/cgi/wiki?CrcCards">CrcCards</a>, and the points mentioned by Kent, Ralph and others above, have worked extremely well.  --<a href="http://c2.com/cgi/wiki?JeanineDeGuzman">JeanineDeGuzman</a>
<p>
<hr>
<a href="http://c2.com/cgi/wiki?StevenNewton">StevenNewton</a> raises an issue I feel compelled to address.  He asks about <em>what happens when someone leaves a project and takes the knowledge of an entire sub-system with him?</em>  The answer is simple.  Never happens.  If you follow the way XP is supposed to work you will be <a href="http://c2.com/cgi/wiki?MovingPeopleAround">MovingPeopleAround</a>.  No one person ever has irreplaceable knowledge.  You do not have &quot;code that only [that] programmer understands&quot;.
<p>
Also, stories are in fact documented (written down) on cards and elsewhere.  They don't just get misplaced.  
<p>
And you can not fix a problem and cause another problem very easy.  The <a href="UnitTests.html">UnitTests</a> will slap you in the face and the <a href="FunctionalTests.html">FunctionalTests</a> will kick you in the ass.  We need to keep in mind that these two test suites are ever evolving. When a new problem is discovered a new test is added.  The safety net becomes ever tighter.  It's part of the discipline that goes with <a href="ExtremeProgramming.html">ExtremeProgramming</a>.  
<p>
As for adding complexity to justify <a href="http://c2.com/cgi/wiki?CowboyCoding">CowboyCoding</a>, I think I see what you are asking.  The actual practice of <a href="ExtremeProgramming.html">ExtremeProgramming</a> is very simple.  (Once you get used to a few rules it is one of those, <em>duh!</em>, this is so obvious sort of things.)  It is the documentation of said simplicity that is difficult.  Try documenting the CurveOfBeauty<a href="http://c2.com/cgi/wiki?edit=CurveOfBeauty">?</a> with text...very difficult.  But when you see it, you know it!
<p>
Going back to Steven's original metaphor, I assert that traditional programming methodologies are &quot;Ptolemy's terribly complicated but ultimately wrong system&quot; while <a href="ExtremeProgramming.html">ExtremeProgramming</a> is &quot;Copernicus knock[ing] the earth into its proper place&quot;.  Correct me if I am wrong, but wasn't Copernicus branded as a heretic and put into jail for saying that?  At the time no one wanted to hear the truth. --<a href="DonWells.html">DonWells</a>
<p>
<em>You're wrong. Copernicus was never branded a heretic, nor was he ever jailed. At the time a lot of people wanted to hear the truth.</em>
<p>
This is definately good news for Kent!
<p>
(He's thinking of Galileo; censured by the Catholic Church for publishing work based on Copernicus' sun-centered ideas.  A lot of history is being misinterpreted in this thread.  ;-)
<hr>
<em>Copernicus did not <a href="http://c2.com/cgi/wiki?OnlySayThingsThatCanBeHeard">OnlySayThingsThatCanBeHeard</a></em>
<hr>
Perhaps Steven is referring to <a href="http://c2.com/cgi/wiki?ExtremeMaintenance">ExtremeMaintenance</a> and how that would work.
<hr>
A couple more thoughts on why I think XP is not, as Steven asserted, &quot;just a codification of bad programming practices in bad environments.&quot;  One key point I haven't seen in the arguments here are the constraining (read improving) effects that <a href="PairProgramming.html">PairProgramming</a> places on rogue programmers with a <a href="http://c2.com/cgi/wiki?JangIt">JangIt</a> mentality.  Even if you tend to have cowboy coders in your group, pairing them up with an experienced XP'er virtually guarantees the code will be written properly and the necessary testing will also be put in place.  Even if two JANGmeisters are paired together (and the rest of the team will know when they are) the resulting code will still be better than if either went off on their own.  While not the most desirable scenario, as discussed in other pages (<a href="http://c2.com/cgi/wiki?VcapsProject">VcapsProject</a>, <a href="PairProgramming.html">PairProgramming</a>), it still provides a certain set of checks and balances between the two since no two people think alike.  Since the rest of the team knows about the volatile pair, any offending code will be corrected during <a href="http://c2.com/cgi/wiki?ExtremeProgrammingCodeReviews">ExtremeProgrammingCodeReviews</a>.  In other words, the team knows what code is going to have to be reviewed more thoroughly when certain pairs are put together (it's just a reality of working in groups).  When combined with the other factors of XP what results is the <strong>elimination</strong> of bad programming practices and bad environments.  
<p>
Pairing also gets rid of any problems resulting from <em>mediocre</em> programmers writing poor code and documentation, as mentioned above.  It seems the dissenting opinions keep forgetting that arguing against one particular aspect of XP  won't work because it is the other aspects that balance out most of the possible negative side effects when taken individually.
<p>
FYI, I'm speaking from the point of personal experience in that I didn't think <a href="PairProgramming.html">PairProgramming</a> was going to help me improve my code and make me faster.  So I went in quite skeptical.  As you can tell, my views have changed just a bit.  --<a href="http://c2.com/cgi/wiki?TomKubit">TomKubit</a>
<p>
<p>
<hr>
XP is not a 'pseudo-Methodology' as Steven asserts above that is allowing 'proponents of this technique have simply given a name to poor
programming practices'.  The XP methodology does, however, require a mental attitude that embraces change, and a willingness to learn, not only from ourselves but from others.   One of the strongest strengths in XP is <a href="PairProgramming.html">PairProgramming</a>.  We have found that the interactions that happen within a pair team is vastly more than the sum of the parts would produce.  Even the most experienced coder finds that they are producing a design/code that is at a much higher level than they could do alone.  We have found on the <a href="http://c2.com/cgi/wiki?VcapsProject">VcapsProject</a> that there is typically less indecision in a pair team, ideas are thrown back and forth, and the solution space is quickly narrowed as advantages and disadvantages are discussed within a pair team.  XP is a philosophy, a methodolgy that I strongly believe in. --<a href="http://c2.com/cgi/wiki?KevinBradtke">KevinBradtke</a>
<hr>
[Next append moved to <a href="ThoughtfulReactionsToXp.html">ThoughtfulReactionsToXp</a>, where there is more space for considered responses}
<hr>
<a href="http://c2.com/cgi/wiki?edit=XpIsaPseudoMethodology">EditText</a> of this page (last edited October 23, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=XpIsaPseudoMethodology">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>