bigdesignupfront.html

极限编程 Extream Programing

I'm big on design, compared to many here (to me the work is in design; coding
is the process of converting that into a specific computer language and typing
it in, and occurs quickly and semi-automatically) but always within that
context of a larger cycle.  This <a href="BigDesignUpFront.html">BigDesignUpFront</a> thing as described
seems to be trouble waiting to happen.  --<a href="http://c2.com/cgi/wiki?JimPerry">JimPerry</a>
<hr>
What is the problem statement that <a href="ExtremeProgramming.html">ExtremeProgramming</a> is a good solution for?  What is the problem statement that <a href="BigDesignUpFront.html">BigDesignUpFront</a> is a good solution for?  I read that Nickolas Tesla pictured a fully designed and working alternating current generator in his head before he even started working on one.
<p>
Maybe <a href="BigDesignUpFront.html">BigDesignUpFront</a> is the correct solution when you already know everything you need to know and are ever going to know about a system before you start it.  Why experiment and iterate if you aren't going to learn something?
<p>
<em>Sounds impossible as stated, boring if it were.  If I knew everything, wouldn't I know the design and not need <a href="BigDesignUpFront.html">BigDesignUpFront</a>?  --r</em>
<p>
Maybe <a href="BigDesignUpFront.html">BigDesignUpFront</a> is the correct solution when the medium you are working in is incomprehensible once it is built/written (e.g. machine code).
<p>
<em>No one ever built a machine code program without debugging.  We used to do lots of thinking and desk checking not because it was better than debugging, but because it was hard to get time on the machine.  --r</em>
<p>
Maybe <a href="BigDesignUpFront.html">BigDesignUpFront</a> is the currect solution when the medium you are working in is unchangeable once it is built/written (e.g. Hubble Telescope). 
<p>
<em>Actually the Hubble was built on the ground, and changed in space.  I think, though, that the learning point is most important. You will learn: what's the best way in your circumstances? --<a href="RonJeffries.html">RonJeffries</a></em> 
<p>
<p>
--<a href="http://c2.com/cgi/wiki?StanSilver">StanSilver</a>
<hr>
To continue my last statement:  Where is the most efficient and cost effective time and medium to do your experimenting, tinkering, and rearranging?
<p>
Maybe the primary purpose (primary use?) of design notations is for tinkering, not for specifying?  Maybe the better they are for specifying, the worse they are for tinkering, so the complicated ones don't get used?
<p>
If I understand correctly, XPers seem to have come to the conclusion that stories, CRC, units tests, Smalltalk (and Wiki?) are the best phases/mediums for doing their tinkering and rearranging.  Others do major tinkering in some design phase/design notation during iterations; still others do major tinkering in a big design phase/design notation at the beginning of a project.  --<a href="http://c2.com/cgi/wiki?StanSilver">StanSilver</a>
<hr>
Another angle (to steal a knowledge representation technique from <a href="http://c2.com/cgi/wiki?WhatIsAnalysis">WhatIsAnalysis</a> page):
<UL>
<li> <strong>Group 0</strong>, software development is a trial and error process
<li> <strong>Group 1</strong>, software development is a series of deterministic transformations
</UL>
Group 0 tries to partition their trial and error (into different mediums and time intervals) in a way that minimizes cost and time to market.
<p>
Group 1 concerns themselves with specifying and capturing the complete and correct output of each transformation phase (since the assumption is that it is correct).
<p>
When some of group 1's code isn't accepted by the user, it is a &quot;mistake&quot; - they didn't do one of their transformations correctly.  When some of group 0's code isn't accepted by the user, they fix it.  --<a href="http://c2.com/cgi/wiki?StanSilver">StanSilver</a>
<hr>
I like that characterization :-) --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>
<hr>
Two comments:
<UL>
<li> I'm never sure whether the word `design` means what some thing looks like to the user, or what it looks like to the people creating and/or fixing
</UL>
the same thing.
<UL>
<li> The best size of ``design up front`` surely depends on both the sitution, and how fast that situation is changing.
<p>
</UL>
--<a href="http://c2.com/cgi/wiki?DickBotting">DickBotting</a>
<p>
'Design' has to be one of the most over-used and mis-used words around at present.
Consider whether other words are really meant, eg 'make', 'write' etc.
For me 'Design' encompasses a wide ranging process of investigation, evaluation, problem-solving and creative decision-making. Thoughtful analysis is the key to this.
<p>
The outrage of so much of modern (building/environmental) 'design' is that there is clearly no commitment to this process of thoughtful analysis, just a quick, commercially led and superficial decision-making process that only just precedes the actual making of the building by the Contractors.
<p>
-- <a href="http://c2.com/cgi/wiki?MartinNoutch">MartinNoutch</a>
<p>
<hr>
A nice quote from a &quot;<a href="http://c2.com/cgi/wiki?MurphysLaw">MurphysLaw</a>&quot; calendar we have at work:
<p>
<DL>
<dt> <dd>Reisner's Rule of Conceptual Inertia
<dt> <dd>&quot;If you think big enough, you'll never have to do it.&quot;
<p>
</DL>
What is it that makes some of us want to procrastinate, often in very creative ways?  I think this may be part of the dynamic of <a href="BigDesignUpFront.html">BigDesignUpFront</a>.
<p>
--<a href="http://c2.com/cgi/wiki?JeffMantei">JeffMantei</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=BigDesignUpFront">EditText</a> of this page (last edited December 5, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=BigDesignUpFront">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>