Source Code Is Design Requires Inversability

For TheSourceCodeIsTheDesign to be true it must satisfy the invertibility property: The original use cases must be derivable from the source code.

In the same way that you must be able to derive the original blueprints from looking at a skyscraper as built?

[More than that, you must be able to derive the intent and purpose of the builder from the blueprints. That's easy. The intent and purpose is always to make more money.]

{Wait a minute -- the test you are proposing would demonstrate TheSourceCodeIsTheRequirements?, not the design. -- JeffreyHantin}

The experiment would be to create a reasonably complex project with a set of use cases. Have this project be coded by a team. Let the project undergo several enhancement and release cycles. Then take another team. Have them look at the code. Create the set of uses cases they think describe the code.

If the first groups use cases do not match the second group's use cases to a close degree then the source code can't be the design.

Hypothesis about why this won't work:

Code is not expressive enough to reveal intent and purpose. An implementation may have 20 forces on it reacting to the entire set of use cases, but you basically only have method names, class names, and variable names in which to express the forces.
Runtime execution is extremely difficult to predict from source code. Much code is the subtle expression of runtime behaviour.

Are you claiming that the use cases are the design?

No, I am claiming the entire system embodies the design, but for the case for TheSourceCodeIsTheDesign to be true inversability must be true because the source code is said to embody intent and purpose. If this is true then the use cases are derivable.

Since when have most other designs actually contained "intent and purpose"? Once they're handed over by the analyst, they're just lists of things that should happen. They rarely explain why.

XP claims TheSourceCodeIsTheDesign, not me. That means the code is understandable on its own, without reference to anything but the source code. This includes unit tests. Unit tests are said to be requirements.

The design for a nuclear bomb cannot be used to derive 'use cases'. Inversability is nice to have, but it's not a requirement for a design. Besides, automated UnitTests and good ReFactoring provide all the inversability you would need. If you need more inversability, write more and better tests. Why this reliance on capturing it all in code? Because TheSourceCodeIsTheDesign (i.e. the only one that counts).

Passing this test is trivial. Write the use cases as source code.

Please show me. If you're doing XP just look at the acceptance test scripts and you have all the inversability you need.

Use case:

System A sends a message to System B. System B processes the message and sends a response message to System A.

Equivalent code in System A:

 Message response = SystemB.processMessage(aMessage);

That the purpose "is always to make more money", is a contemporary cynical view, Some times skyscrapers are built to be known for something special, such as being the tallest building in the world, and other times to be pleasing to the eye, properly and centrally placed and practically useful. To say the design "must be deriveable from the source code" is to ignore those who use and appreciate the advantages and beauty of the "design". It is like saying that one must be aware of how many 2 by 4's are used in the construction of a residence. Most home owners who are drawn by the design and allocation and provision of livable spaces to the point of purchasing the home and could care less about the artifacts of construction (which include blueprints and building materials). In the broadest sense "design" is perceivable by sensations about the physical artifact, and not by the narrower "design" which is seen by the producers of plans and the assemblers of components. The oft repeated phrase "beauty is in the eye of the beholder" might be restated to express this notion by "design is sensed by users of the spaces". -- DonaldNoyes 20070502

The author makes no claim, Donald, that TheSourceCodeIsTheDesign... only that if TheSourceCodeIsTheDesign (as some claim) then there are some properties it must fulfill. In particular, if the source code is the design, then the design is (or directly translates into) the source code, and anything that can be derived from the design can be derived from the source code. One example the author offers, in particular, is the set of use-cases. I'm not convinced that use-cases can be derived from design, but I'm also not an XP programmer where use-cases are essentially the high-level program component that determines everything in the program... where the use-cases are the design. I do know that TheSourceCodeIsTheDesign often holds true in at least a few programming languages... e.g. graphical languages for network or circuit design. Most often, the design is higher level than the source code or blueprints.

Your analogy involving houses, beauty, and 2x4 boards has relevance. In the situation you proffer, the 'design' is high level: how light will reflect off the rooftops, how air will flow through the kitchen, beauty and livability. How, then, could you get away with saying that "the blueprint is the design"? Short answer: you cannot! The blueprint, here, derives from the design, and is not inversible... therefore the blue print is not the design. Putting this back into the example of source-code, for "the source code to be the design" in this case, one would essentially need a DomainSpecificLanguage with ConstraintsBasedProgramming?... such that you write down (as your 'source code') such things as: how light will reflect off the rooftops, how air will flow through the kitchen, beauty and livability. Then out pops a model house and associated blueprints that meet the constraints.

A skeptic above states: "the design for a nuclear bomb cannot be used to derive 'use cases'." Sure it can. The design behind a nuclear bomb was essentially: 'bomb powerful enough to stop a war'. That's a use-case right there. The blueprints and actual construction of a nuclear bomb are not its design... they derive from its design. The fact that there are many different blueprints and constructions that one can call 'nuclear bombs' is indicative of this fact. The fact that the blueprints and constructions cannot be inverted to derive the 'use cases', as you say, is also indicative of something: the blueprints are not the design.

How, then, could you get away with saying that "the blueprint is the design?

I said of blueprints:

"the artifacts of construction (which include blueprints and building materials)"

What I would like to emphasize is that "Design" emcompasses far more than the artifacts which produce a physical entity, and that the plans for an assembly process is not "Design". It might more properly be called "Configuration", "Specification" or "Alignment".

-- DonaldNoyes 20070503

The question was rhetorical. I agree with your overall statement... though I consider the specification to be the design more than anything else (how else do you go about designing something than specifying certain features, requirements, capabilities, desires?).

That is "how" you begin designing. You must first have some "Overall or All-Encompassing" notion of what you want. It is at first an Incompleted MentalImage viewed "at a distance". It engenders a feeling of possibilites, of becoming a SatisficingArtifact?. For example, suppose you are going to design an automobile. You may have included in a MentalImage, what you want the car to "be". It may include: low cost, snappy acceleration, soft ride, roominess, unrestricted view, hauling capacity, environmental friendliness, fuel conservation, serviceable, many hi-tech devices, safety, and so on. These represent some of the many things you have an image of and which will require trade-offs to obtain a formulation of what you will be satisfied with. While they are "features, requirements, capabilities, and desires", they have yet to "realized". Design involves making these things "actual". This abstraction, or MentalImage, serves as a revisable guide. -- DonaldNoyes 20070503

So specification is what happens before design, then. After all, that "Overall or All-Encompassing" notion of what you want IS a specification. And it can only be expressed or communicated in a language that allows you to express specifications... such as mental images and English. If I have a mental image and have difficulty translating it to English, that's just a translation problem. Quite fundamentally, any answer to "What do you want?" is a specification. And if specification is what happens before design, the design process itself must (fundamentally) be a constraints resolution problem... finding a way (a plan) to meet those specifications and other imposed constraints (time limits, cost limits, laws, physics, etc.)). In that sense, every design process is a planning process and every design is a type of plan.

Anyhow, source code is a product, not a process. Thus, in the context of 'TheSourceCodeIsTheDesign', you must consider the design to be the product of the mind (the specification) or the product of the design process (the blueprint/model/plan that meets all specifications and constraints), or some amalgamation of the two. You're seeming rather contrary to me in rejecting the former as "how you begin designing" and rejecting the latter as "the artifacts which produce a physical entity". By your notions, there is no such thing as a design... certainly nothing you could ever point at. You'll be waving your hands around like a stage magician, initially trying to to find a design then finally obscuring the fact that you defined design out of existence.

I'm not one to accept vague definitions when organizing my own thoughts. To me, the design = specification. The blueprints/models/plans are also designs (as they, themselves, are specifications with regards to the next step in the engineering process... the path from blueprint to final construct will involve many more planning stages). But I won't honor them with "the". That article is reserved for the original source from which all following plans and designs ultimately derive... the product of the mind, that mental image and any linguistic translation thereof, that answer to "What do you want?". If there is re-vision of the original vision as a result of being unable to meet the original specifications (e.g. because they're too expensive, impractical, etc... i.e. "impossible!" is returned from the design process), then I suppose you could say that the design is this final revision, this final specification. Still, it's a specification.

Thus, if TheSourceCodeIsTheDesign, that answer to "WhatDoYouWant?" must be derivable directly from the code... and vice versa. For this to be true, the intent of the designer or programmer must be expressed directly as a real part of the source code. The ability to derive use-cases from the code would, necessarily, be doable for code where "WhatDoYouWant?" is answered by a stack of use-cases.

I'll disagree on your final point. To me, that car ain't real until someone can hop in and drive around. That moves past design and engineering and right on into prototyping.