📄 isextremeprogrammingwacko.html
字号:
<head><title>Is Extreme Programming Wacko</title></head><body><h1><img src="logo.gif"> Is Extreme Programming Wacko</h1><a href="ExtremeProgramming.html">ExtremeProgramming</a> must be <strong><em>WACKO!!!</strong></em>
<p>If you let the <a href="http://c2.com/cgi/wiki?CowboyCoder">CowboyCoder</a><em></em>s loose, without doing any design, the resulting system is inevitably a big mess.
<p><hr>
<p><strong>We emphatically do not recommend doing no design.</strong> We do, however, recommend doing far less paper, UML, Jwhatnot design. We recommend doing a bit of CRC to set your direction, then implementing the objects to ask them how they really want to be designed.
We <em>discover</em> good design by implementing the system and by making sure we <a href="RefactorMercilessly.html">RefactorMercilessly</a> every time we learn something. This form of combined design/development goes much faster than the longer cycle that is an inevitable part of paper design.
<p>Most of the projects we read about that result in bad software, overruns, and death marches are in fact top heavy with requirements and big design. There is a famous definition of insanity: doing the same thing over and over again and expecting different results.
<p>In part, we can get away with this because we do not allow "crap" code in the system. We don't write it intentionally; we refactor it when it comes out of our fingers anyway; we refactor it when we stumble across it after not doing it perfectly the last time. If you ran across some bad code in something I wrote, you would fix it - probably sitting down with me to do it. If a programmer persists in writing code that doesn't meet our standards, we remove him from the project, probably before he gets back from Israel.
<p>Extreme programmers do understand their problem - and have dedicated customers with them to be sure that they do. Extreme programmers have live, ongoing analysis, not a dry and out of date document.
<p>Extreme programmers do design. We take time up front to choose the <a href="SystemMetaphor.html">SystemMetaphor</a> (architecture). We CRC whenever it isn't clear how to build something; we let the code tell us how the objects really want to interact, and we change them (i.e. change the design) when we learn that. In <a href="ExtremeProgramming.html">ExtremeProgramming</a>, <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>.
<p>Again: we do not advocate no design at all. We do advocate jumping quickly into code, because that is where you can really learn the fastest. We jump into code, however, in the context of a very tight discipline of writing quality code, and keeping the code at very high quality. Without that discipline, we could still learn ... but then we'd have to reimplement what you had learned.
<p>XP has been shown to be able to handle very complex problems. C3 has over 2,000 classes and 30,000 methods, and has been evolving while in production for 18 months without bogging down. <a href="http://c2.com/cgi/wiki?WyCash">WyCash</a> went on for years and never buried itself. This ain't no backroom operation. XP is a serious discipline that does in fact challenge some "conventional wisdom". It does so based on past and continuing success of teams that know how to produce quality large-scale software while maintaining the productivity of small entrepreneurial development teams.
<p>Thanks for continuing to challenge these ideas - it helps us express them more and more clearly (I hope), which is key to our ultimately getting them across in book and speech. --<a href="RonJeffries.html">RonJeffries</a>
<p><hr>
<p>For the opportunity of enhancing my understanding of XP, I would like to offer another answer to the design question. The issues seems to be related to the DistanceBetweenDesignAndCode<a href="http://c2.com/cgi/wiki?edit=DistanceBetweenDesignAndCode">?</a>. My understanding is that the XP practice is to test design ideas as soon as possible, and the way to test out a design idea is to write a test, then implement the code. If you can get feedback the same day it is good, but within the same work session is better. So deal out those CRC cards, make it work with the cards and then ProveItInCode<a href="http://c2.com/cgi/wiki?edit=ProveItInCode">?</a>.
<p>The problem with <a href="BigDesignUpFront.html">BigDesignUpFront</a> is that it can take ages before the design ideas get tested out in running code. On a project I am aware of that very nearly did a CrashAndBurn<a href="http://c2.com/cgi/wiki?edit=CrashAndBurn">?</a>, coding did not start until the 6th month of an 8 month project. Luckily the design was not too far off, but the project missed many essential requirements that only became visible when thecustomer saw the system in the 9th month. <a href="http://c2.com/cgi/wiki?SoftwareEngineering">SoftwareEngineering</a> types may say that the project should have done more Requirements work, but 3 months out of 8 should have been enough. With the ExtremeApproach<a href="http://c2.com/cgi/wiki?edit=ExtremeApproach">?</a>, end user validation of the system could have started in month 2, not month 7.
<p>For all future projects I intend to minimize the DistanceBetweenDesignAndCode<a href="http://c2.com/cgi/wiki?edit=DistanceBetweenDesignAndCode">?</a>.
<p>There will always, however, be a larger DistanceBetweenRequirementsAndDesign<a href="http://c2.com/cgi/wiki?edit=DistanceBetweenRequirementsAndDesign">?</a>, so you need a lightweight mechanism like <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> to <a href="http://c2.com/cgi/wiki?CaptureRequirementsForPrioritization">CaptureRequirementsForPrioritization</a>. So when scoping out the project you capture a lot of requirements, you agree to the general development sequence, and then you work down the list. The lower priority ones will take 12 months or more to get to, hence the larger DistanceBetweenRequirementsAndDesign<a href="http://c2.com/cgi/wiki?edit=DistanceBetweenRequirementsAndDesign">?</a>.
<p>When the requirement gets near to the head of the queue, you need a mechanism to <a href="http://c2.com/cgi/wiki?CaptureRequirementsForImplementation">CaptureRequirementsForImplementation</a>, often through the more complete <a href="http://c2.com/cgi/wiki?UseCase">UseCase</a> mechanism. Or you can use the ExtremeApproach<a href="http://c2.com/cgi/wiki?edit=ExtremeApproach">?</a> and using the <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> as a reminder, actually TalkToTheUsers<a href="http://c2.com/cgi/wiki?edit=TalkToTheUsers">?</a>, find out what they really want now, and then get the Users to write the tests.
<p>--<a href="http://c2.com/cgi/wiki?PeteMcBreen">PeteMcBreen</a>
<p><em>Right on, Pete! --rj</em>
<p><hr>
<p>I think <a href="http://c2.com/cgi/wiki?JimPerry">JimPerry</a> said "the less you understand about the problem, the more you should design before coding". I believe just the opposite is true. It is when I write the code that I learn. It is not until I learn that I get the design right. Therefore, I should defer as many design decisions as possible (but not more) until after I have coded.
<p>How many guesses do you want in the system (design or implementation) at one time? My answer is "1". I want to put one guess in there. Then I want to test it. If it is wrong, I change it. If it is right, it isn't a guess. Then I can guess again if need be.
<p>The example above of the guy writing what sounds like a horrifically complex piece of software is not extreme in a bunch of ways. Is it possible that a simpler design could have solved today's problem? Were there reasonable functional and unit tests for what was coded so far? Was there any code in the system that had been written but not completed enough for testing?
<p>Once again, XP spends much more time on design than other processes I have used. It just spreads the time out over the whole project, rather than concentrate it in the beginning when you are ignorant. I think the rest of the world is wacko (which is generally not a good sign, mental-health-wise, but there you have it).
<p>--<a href="KentBeck.html">KentBeck</a>
<p>And another thing- if you design long before you implement, the chances that you will learn from your inevitable mistakes drops dramatically. Learning research tells us that the time lag from experiment to feedback is critical to the speed of learning. 30 seconds works well for me. 6 months does not. --kb
<p><hr>
<p>I actually said "the investment of time in design should be proportional to the complexity and (un)familiarity of the task at hand", which I consider to be valid and not particularly in conflict with what Kent said above, unless wrenched thoroughly out of context. (I don't say all design should be done before all code, let alone six months before coding, and I have no problem with experimental code for learning; I would categorize a <a href="SpikeSolution.html">SpikeSolution</a> as design exercise).
<p>Which is not to say that I think all programmers thrive on the same precise model. I do work better when I do design in a different medium than code; sometimes wholly mental, sometimes sketches on paper, sometimes mathematical models, etc. I learn a lot during that phase, but not usually from writing the results down as code. YMMV. --<a href="http://c2.com/cgi/wiki?JimPerry">JimPerry</a>
<p><hr>
<p>At a leading consulting company, I experienced several projects with fortune 500 companies in America and Europe. They had a proprietary methodology that followed the <a href="http://c2.com/cgi/wiki?WaterFall">WaterFall</a> method of software development. It started with an inception phase, spent two weeks doing a rapid prototyping session, and had design, development, then rollout phases. Many projects suffered from the usual problems. One out of twenty were highly successful. The rest were ugly, nefarious, and driven by business imperative. In other words, their phases each focused on selling the next phase and this usually drove the process.
<p>The prototyping phase was essentially a throw-away, primarily intended to get stakeholders and executives motivated enough to put their checkbooks on the table and sign up for design and development.
<p>In design, you really did an analysis that didn't address important issues, and failed to understand risk. Spin doctors who couldn't do anything, but were like heroin when they talked about it, drove the process. At the end of design, you had disgruntled technical people complaining that it wasn't finished, a hurry at the management level to start development, and a fat 1000-page design document that mostly contained useless specs that were out of date before they were printed.
<p>Development started with people who hadn't been there during design, likely didn't have experience in the technologies used, and project managers tended to be totally non-technical that had a difficult time managing scope (and subsequently risk). During the last half of the original time slated for development, people were expected to work 12-16 hours per day, and eventually every weekend. System test would be around the corner, and you had a huge, bloated system that was untestable, not being tested, and usually lower priority subsystems either hadn't been developed yet or had been neglected in one way or another.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -