I think JackReeves' article on WhatIsSoftwareDesign 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. 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. Most computer systems are stable from the compiler down to the execution of binary instructions. Therefore, it's natural to think of "product" 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 "designs" or "specifications". I think it's the lack of a direct and strictly repeatable translation of these artifacts that characterizes them. ("Specification" 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. It seems wrong to say that any one of these tenuously connected artifacts is the design. Unless, of course, it's the only document you have . 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? -- WaldenMathews ---- Thinking of the source code as the product is probably wrong. See TheSourceCodeIsTheDesign. ''Please note that there is continuous and heated debate over this issue; this is one of those lifelong arguments that will plague Wiki forevermore.''