thesourcecodeisthedesign.html

极限编程 Extream Programing

<em>Huh? You fix your software by tweaking its binary components?</em>
<p>
As a <em>consumer</em> of both cars and software, I typically don't tweak; I replace.  When my car's CV boot breaks, I replace it.  When some component of my IDE starts acting flaky, I re-install that component from the CD.  In other words, I fix by replacing.
<p>
To carry the analogy further, when a software company discovers a design defect, they issue a &quot;service pack&quot;, which typically updates only one or a few components.  This is analogous to a car manufacturer discovering a design flaw in a component in a car, redesigning the component, and then getting people to replace the component.  (Of course, software companies also have the luxury of being able to issue a completely new version of the software very cheaply.  Car manufacturers don't give you a brand new car unless they <em>really</em> screwed up.  But that's manufacturing economics, not design.)
<p>
And the owners manual and service manual for a car aren't the design.  They're end user documents, just like the user and administrator manuals for a complex piece of software.  Car manufacturers almost never give out the actual design artifacts for a car, which these days consist of CAD files, PLC programs for the robots, and dies for stamping out the parts.  Third party auto part manufacturers have to reverse engineer these.  -- <a href="http://c2.com/cgi/wiki?JohnBrewer">JohnBrewer</a>
<p>
I think the poster of the car analogies point was that even a skilled repair man needs documentation beyond the implementation. You've gone through a lot of effort to disprove his/her position by extending the analogy in all sorts of ways it was beyond the orignal intent. You'd have to ask the original poster, but my guess is s/he was only drammatizing the need for designs beyond the raw parts. Personally, I think you are missing many of the subtleties associated with software engineering by working so hard to prove your analogies. I mean, what if you discovered that your analogies broke down all of the sudden? Would you start developing software in another way that <em>was</em> more analogous to manufacturing or hard-engineering? One of Reeves first points was that neither analogy holds up when extended.  I mean, how can we debate whether or not software should have any upfront design based on whether or not a car has a design beyond its parts. Do you really think that a software binary is the same as a car? Yikes! The longer this page gets the more ludicrous each side of the argument seems. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
<em>No, I strongly doubt anybody thinks a software binary is the same as a car; it's <strong>analogous</strong> to a car, within the scope of a particular analogy.  And the point of the analogy is explicitly to demonstrate how different software and (e.g.) cars are.  (And, for what it's worth, <strong>all</strong> analogies break down when extended too far; if they could be extended forever with perfect correspondence, the term &quot;analogy&quot; would no longer be appropriate.)  --Glenn Vanderburg (being pedantic again)</em>
<p>
<hr>
<p>
Wow! That was great. Clearly, the <a href="http://c2.com/cgi/wiki?SourceCode">SourceCode</a> is only <em>one view of the design</em>. This is another XP simplification that can often lead people to trouble. You may also want to tell drivers going over the Willamette that the Bridge they are riding on was constructed with none of that evil DesignUpfront<a href="http://c2.com/cgi/wiki?edit=DesignUpfront">?</a>. And, whenever it is in need of repair, <em>even by experts</em>, that they need no engineering schemata because the girders, welds, and rivets <em>are</em> the design. I'm tending to think all of these analogies (mine included) lead to frightening conclusions if extended. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
I want to ammend my comments and say that I believe <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> is a bit of a fallacy and that <a href="http://c2.com/cgi/wiki?TheSourceCodeIsTheSpecification">TheSourceCodeIsTheSpecification</a> is probably a little closer to the truth. It used to be that engineers would create designs, specifications, and then implementation. I believe, especially with the languages of today that specification is no longer necessary because <a href="http://c2.com/cgi/wiki?TheSourceCodeIsTheSpecification">TheSourceCodeIsTheSpecification</a>. However, I do <strong>not</strong> believe that <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> -- but I do think it is a nice ethic. However, it could be that as languages improve and become more high-level that we will be able to attain <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>. It's just not true of our existing languages. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
Robert, have you read the article that is mentioned at the start of this page?
The primary thesis of the article is that, compared to physical engineering and
manufacturing, <em>software is fundamentally different</em>.  In software, we're
blessed with an extraordinarily cheap manufacturing process (type &quot;make&quot;).
So of course we go back and change the design; it's a lot more accessible and
amenable to change than the artifact, and going from the design to the artifact
is trivial.  Not so with a car, so the owner has to fix the artifact.  In your
example, following the mapping described in the <a href="http://c2.com/cgi/wiki?JackReeves">JackReeves</a> article, the car is
<em>clearly</em> analogous to the binary.
<p>
I'm not actually disagreeing with you about the &quot;design vs. specification&quot;
point (although I think the distinction is minor).  I just wanted to point out
that your argument completely misses the point of the original article, which
is well worth reading.  --<a href="http://c2.com/cgi/wiki?GlennVanderburg">GlennVanderburg</a>
<p>
While I haven't read the article for probably five or six years, my point was more about <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> ethic in the large (or at least how it is bandied about on Wiki as a justification for no upfront design). My comments had very little to do with the article. The article is often used to support <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> but I don't believe the whole concept is predicated on the Reeves article. Maybe I'm wrong. However, I don't think you can say I miss the point just because I disagree. FWIW, I'll print it out right now and give it another read but I doubt I'll be more inclined to agree now than I did then. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
Sorry, I didn't mean you'd missed the point.  I was just being narrow and
pedantic (one of my email addresses is [e-mail], for good reason). 
I just don't think your argument about the car supports your view, because
that <em>argument</em> misses the point.  (And, to me at least, the concept <em>is</em>
predicated on the Reeves article.  I held essentially your position until I
read that article, which made a believer out of me.)  ---glv
<p>
Wow, we should have passed in the night. I just moved the other direction a couple of years ago. However, <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> is still close to my heart, I've just seen it break-down too often in complex projects. I've come to think of traditional design documentation as being relevant only when it describes the problem domain and the resulting system at a high-level of abstraction (i.e. roles versus classes). I then view the specification as a detailed view of how the system design is implemented. I suppose this is why, if one must make analogies, that I feel <a href="http://c2.com/cgi/wiki?TheSourceCodeIsTheSpecification">TheSourceCodeIsTheSpecification</a> is more accurate. To me, it didn't even seem like Reeves himself was completely satisfied with either analogy. The truth is probably this...that neither are correct. Programming is probably more like algebra than engineering, but that doesn't even fit completely. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
Well, this goes to what I meant when I said that I thought your distinction
was mostly semantics.  I view the source code (and what you've called the
specifications) as the <em>detailed</em> design, which might be sufficient for
small projects.  But for larger, more complex designs, you might need design
overview documents to introduce you to the design and help you know where to
start.  I don't think many people (even those who believe <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>) would argue with that, and I suspect that the
design of a 747 has some high-level overview documents about the design, even
though what really matters is the detailed design.  So when you say <a href="http://c2.com/cgi/wiki?TheSourceCodeIsTheSpecification">TheSourceCodeIsTheSpecification</a>, it seems to mean the same thing as &quot;the souce code is the detailed design&quot;, which is what I believe.  --glv
<p>
Seems like, besides semantics we agree. Rather than bat around terms that may be ambiguous like <em>design</em> versus <em>detailed design</em> I find it clearer to say <em>design versus specification</em>. However, if we agree on the concepts, that's pretty encourageing and its probably just a waste of time to debate the terms. --<a href="http://c2.com/cgi/wiki?RobertDiFalco">RobertDiFalco</a>
<p>
<hr>
This just occurred to me, but if <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>, then are UML diagrams, etc., merely different views of the design? 
<p>
Shouldn't the tools be used to extract the diagrams from the source code (I know most tools have this option, but using it is usually frowned upon)?  Use Cases may be a problem, but isn't it also a problem when reading source code in determining what end user functions it can perform.  Finally, should refactoring show up as cleaner diagrams? 
<p>
Anyone else care to speculate on how <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> principle could reverse the relationship between UML and source code?
<p>
--<a href="http://c2.com/cgi/wiki?WayneMack">WayneMack</a>
<p>
<hr>
<p>
<a href="http://c2.com/cgi/wiki?ReverseEngineering">ReverseEngineering</a> is all about this reversed relationship, trying to find out how to distill design representations (potentially UML) from the source code.
<p>
--<a href="http://c2.com/cgi/wiki?ArieVanDeursen">ArieVanDeursen</a>
<p>
<hr>
I think the Reeves article touches on a very interesting and subtle phenomenon in human value systems in which intermediate effects come to be valued as much as their end effects, and it gets difficult to tell exactly where the value lies.  When the translation of source code to machine code is highly predictable, it's natural to shift attention to the source, even though no machine can run it directly.  But similarly, machine code has no value when the machine is broken.  Because of the high availability of working machines, we don't have to focus there.  Where we have to focus is all that matters.
<p>
If I look very carefully at anything I value, I see a complex chain of effects feeding it.  Stable systems quickly become taken for granted, so we place our value tokens on the parts of the changing world that matter.  If a design is something other than a product valued for itself, then it is merely some effect that is also a cause in a system stable enough for us to predict a value outcome.
<p>
Most computer systems are stable from the compiler down to the execution of binary instructions.  Therefore, it's natural to think of &quot;product&quot; as the artifact just above that base.  That's language source code.  The system that produces that artifact is still quite unpredictable, so it's not likely we'll shift our orientation.  Artifacts more abstract, be they whatever, will constitute a nebulous range of &quot;designs&quot; or &quot;specifications&quot;.  I think it's the lack of a direct and strictly repeatable translation of these artifacts that characterizes them.  (&quot;Specification&quot; is interesting nomenclature, because it's really the lack of specific-ness that keeps it from being the product.)  Nor is it possible to sort out all the possible forms in this category and give them names.
<p>
It seems wrong to say that any one of these tenuously connected artifacts is <em>the</em> design.  Unless, of course, it's the only document you have &lt;s&gt;.  So, while Reeves has caused me to think in more detail about the chain of effects present in software development, he hasn't convinced me that the source is the design and not the product, practially speaking.  But then he didn't claim to have discovered something of practical value, right?
<p>
-- <a href="http://c2.com/cgi/wiki?WaldenMathews">WaldenMathews</a>
<hr>
How does the idea of <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> hold up after a <a href="http://c2.com/cgi/wiki?SalmonMooseIncident">SalmonMooseIncident</a>? I can imagine it being a problem.  -<a href="http://c2.com/cgi/wiki?KenMegill">KenMegill</a>
<p>
<p>
See <a href="http://c2.com/cgi/wiki?TheAtomIsTheDesign">TheAtomIsTheDesign</a>
<p>
<hr>
This conversation about whether the source code is the design seems confused between what a design is and what a design does.
<p>
The important point to remember is that source-code and binary-code are, for practical considerations, the same thing.  There is a direct relationship between the two forms of the code.  They represent the system.  If the source is wrong, the resulting binary is wrong in exactly the same way.  The compiler assures they both represent the exact same thing, but in different languages. 
<p>
A design is a set of documents that describes what the system should do in the eyes of the customer.  A design starts at a high level and adds detail until it describes the necessities to produce the desired system.  
<p>
A programmer translates the information in the design into some programming language (source code).  This act is the implementation of the design.  There is no guarantee that the implementation matches the design.  Any number of reasons can cause this.	However, this does not mean the design changed, it means the programmed did not follow the design.
<p>
The popular lightweight methodologies (XP, RUP-Light, etc.) do not seem to ignore design, but instead to ignore documenting the design outside of the source code.  This is fine if the source code actually implements the intent.  However, without a higher-level design document, there is no way to verify the source code meets the design requirements.  I.e. the source code exactly documents the implementation, but the implementation does not necessarily match the design.
<p>
A design is a collection of documents.  A design does describe what the system is expected to do.  A design uses various levels of detail to make this description meaningful to persons with varying depths of technical knowledge.
<p>
Source code, on the other hand, merely precisely documents the current implementation.  
<p>
--<a href="http://c2.com/cgi/wiki?ChuckAndersen">ChuckAndersen</a>
<p>
<em>Chuck, you seem to be saying much the same as me, that uncertainty of process dynamically delineates product from design.  However, I am not seeing the light on separating what design </em>is<em> from what it </em>does<em> as you have suggested.  Describing what something does is often the best definition of what it is, also known as operational definition.  Further, your definition of design sounds like my definition of specification.  How do you separate those two? -- <a href="http://c2.com/cgi/wiki?WaldenMathews">WaldenMathews</a></em>
<p>
<hr>
I think I agree with you, but am using different words.  I am simply saying that the design encompasses much more than just the details of the final implementation.  I choose to separate the design from the implementation and I consider the source code part of the implementation.  To me, the design covers everything up to the implementation.  In the old days, we had terms like functional design, detailed design, detailed specification, program specification, etc.  These are all part of design.  They are just different abstractions of design intended for different audiences.  They are all important pieces in the progression toward a working system.
<p>
--<a href="http://c2.com/cgi/wiki?ChuckAndersen">ChuckAndersen</a>
<p>
<hr>
<p>
Suppose you have a document that says what the user wants the software to do. Such a document tells you all the things you <em>cannot</em> rely on as a basis for your design. I call this principle <a href="http://c2.com/cgi/wiki?DecisionsAlwaysChange">DecisionsAlwaysChange</a>. It's the things they don't mention that you can build on.
<hr>
<a href="http://c2.com/cgi/wiki?edit=TheSourceCodeIsTheDesign">EditText</a> of this page (last edited March 27, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=TheSourceCodeIsTheDesign">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>