isextremeprogrammingwacko.html

极限编程 Extream Programing

<p>
The OhShitAlarm<a href="http://c2.com/cgi/wiki?edit=OhShitAlarm">?</a> would go off, meetings would happen, and they would delay the end of development.  In addition, they would fly all kinds of senior technical people in who were to help put out fires and regain control of the project.  Those technical people would ask for an object model, sequence diagrams, and a data model.  They would be given a thousand-page-thick tree-killer, and told <em>here it is, but it's way, way out of date.</em>
<p>
I could continue with the story, but I think you all know how it goes.  Year delay, divorces, resignations, etc.  But the consulting company would <em>still make money</em> and therefore never had a business incentive to improve the methodology.  This still happens today.
<p>
The best thing about XP is that it's all about the developer from the beginning. Up-front analysis (<em>you mean &quot;design?&quot;  <a href="http://c2.com/cgi/wiki?WhatIsAnalysis">WhatIsAnalysis</a>?</em>) through methods like CRC cards, and deriving the <a href="SystemMetaphor.html">SystemMetaphor</a>, are important.  I like to catalogue a set of related patterns at this point as well.  But then, since developers are the ones who will be driving the process of building the system, it only makes sense to test, code, and refactor in what resembles a system indefinitely undergoing design.  During this process, demos are given, users are involved often, alpha, beta, and one or more production versions are released.  At some point the project is stopped.
<p>
I firmly believe processes like <a href="ExtremeProgramming.html">ExtremeProgramming</a> and <a href="http://c2.com/cgi/wiki?ScrumMethodology">ScrumMethodology</a> are where it's at.  I was on a project earlier this year that was a mutt-dog mix of these two methodologies, and it was highly successful.  In closing, I look forward to seeing how XP operates in different contexts such as: distributed teams, mission-critical projects, government projects, projects employing SCM, etc.
<p>
<a href="http://c2.com/cgi/wiki?PhilipEskelin">PhilipEskelin</a>
<p>
<hr>
<p>
<DL>
<dt> <dd>&quot;Learning research tells us that the time lag from experiment to feedback is critical...&quot; -- <a href="KentBeck.html">KentBeck</a>
<p>
</DL>
Wow! That's a really, <em>really</em> good point.  I had not made that connection before, but as I look back I see hints. This meshes well with the <a href="http://c2.com/cgi/wiki?ProgrammingIsSocialLearning">ProgrammingIsSocialLearning</a> idea.  Paper designers have to wait days or weeks in a SpiralModel<a href="http://c2.com/cgi/wiki?edit=SpiralModel">?</a> -- they are going to have to re-learn their design before they can understand the lessons of what was built from them.
<p>
Good point! Highlight it in your new book, Kent!  (-:
<p>
<PRE>
    -- <a href="http://c2.com/cgi/wiki?BillTrost">BillTrost</a>
<p>
</PRE>
<hr>
<p>
OK, something still bugs me about all this.  I agree that a paper-light system has its benefits, but the model being proposed seems to require perfect memories of the developers and the customers.  In my experience (although of course, it's only <a href="http://c2.com/cgi/wiki?AlmostExtremeProgramming">AlmostExtremeProgramming</a>) you sit with acustomer, have a rambling conversation about a change and then have to carry it all in your head until it's all down in code.  If the change impacts several objects or subsystems it might take some tme to get it all coded and it's very easy to get interrupted, distracted, or just lose the thread.
<p>
I find that holding details in memory is one of the major sources of <a href="http://c2.com/cgi/wiki?ProgrammingStress">ProgrammingStress</a>, and I try to minimize it wherever I can.  Is there a facet of Xp which solves this problem, or does it really require superhuman memory-monsters or no interruptions?
<p>
-- <a href="http://c2.com/cgi/wiki?FrankCarver">FrankCarver</a>
<p>
<em>Address tasks taking about a day's coding. Sit with the customer. Ask questions. Move cards around (with the customer and some developers) until you know the gist of what you intend to implement. Write some notes on a card. Turn immediately to your computer. Write the test for what you are about to implement. Implement just that much, simply. Test it. Make it work. Make it right. Be done same day. Flush memory, throw card away.</em>
<p>
<em>The above sounds flip. It isn't. If you only have to hold one thing in your mind, your mind can probably hack it. Give it a shot. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
<em>In your terms, now that I've viewed the <a href="http://c2.com/cgi/wiki?GoldenRules">GoldenRules</a> (see <a href="http://c2.com/cgi/wiki?StressFreeProgramming">StressFreeProgramming</a>): we're working in very small chunks, all the way from user stories down to code; we work together with customers and developers to understand; we test like madmen; we work in small time chunks. Eerily similar ideas, n'est pas? --rj</em>
<p>
Aaah.  What I was missing from the rest of the stuff I've seen here about XP
is that small mention of &quot;write some notes on a card&quot;, and the implicit use of
the card in coding.  In fact in one of the CRC pages (reference anyone?) a mention is made of sorting out the solution using the cards, throwing the cards away and _then_ starting coding.  I can't help thinking that this is the wrong way round, or at least that <em>some</em> notes have to be taken.  All it would take is a lengthy support call, fire drill, distracting world event on the web etc.
and all that hard work is thrown away.  Or have you found out some way of preventing or catering for such interruptions?
<p>
-- <a href="http://c2.com/cgi/wiki?FrankCarver">FrankCarver</a>
<p>
<hr>
<p>
We work in pairs, which helps. Lots of people write things down on a card if they think they can't remember between morning and afternoon. The thing we <strong>don't</strong> do is to write them up as a document, which takes time and generates no real light. Catering to things that rarely happen, like fire drills and world events, is probably not worth an investment. There's nothing really
<em>wrong</em> with thinking about things twice once in a while, especially if it saves time overall.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<hr>
<p>
A couple of things struck me as I read all this -- one is the emphasis in <a href="ExtremeProgramming.html">ExtremeProgramming</a> on coding and design being intimate with the coding.  I think that is exactly right.  One of the big problems is the idea that people who don't even know how to code can somehow generate good designs for programmers to implement.  That is largely nonsense.
<p>
The early days of HOLs you would find people talking about languages being self-documenting.  That goal was largely abandoned, and I think to all our our detriment.  We have programmers writing priestly code that is almost unreadable by another programmer.  There was a book called the <em>C Puzzle Book</em> which gave a line of code and said &quot;What does this do?&quot; -- Phillip Kahn called C a write only language and then gave in and generated Turbo C.  Design ought to become an integral part of coding and good language helps that.  XP is a step in the right direction I think but it is easy to abuse and I think it is hard to institutionalize.  A few examples: 1) <a href="PairProgramming.html">PairProgramming</a> will generally be seen by management as having two people do one job (very unpopular idea), 2) Do the Simplest Thing Possible -- will be taken as don't really think the problem through just throw code down on paper (oops dating myself there ...) ... there is no doubt that XP is Extreme and will take some selling.  Wacko it is not!  I think a serious question is whether it scales?  --<a href="http://c2.com/cgi/wiki?RaySchneider">RaySchneider</a>
<p>
<em>Why should it scale?  What if it is exactly good at what it claims it is good at?  Just leave it at that? --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a></em>
<p>
<hr>
<p>
Beyond &quot;one-liner&quot; APL programs, quite a few C programmers have gone out of their way to demonstrate their ability to write code that &quot;can't be understood.&quot;
See <a href="http://c2.com/cgi/wiki?ObfuscatedCee">ObfuscatedCee</a> for more on the &quot;C Puzzle Book&quot; and the &quot;Obfuscated C programming <strong><em>contest&quot;!!!</strong></em>
<hr>
<a href="http://c2.com/cgi/wiki?edit=IsExtremeProgrammingWacko">EditText</a> of this page (last edited August 21, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=IsExtremeProgrammingWacko">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>