Design-Code Strange Loop

Partly inspired by Hofstadter's GEB, this exchange loosely follows the form of a Socratic dialogue, probably best known as the form of Plato's Republic.

Hmmm I have some major concerns with these statements. First of all, there is no separation between design and implementation (coding). Each step of coding is detailed design. Each part of design is influenced by the code.

Ron Jeffries and I both agree with you that the way should be as you say it is.

XP does support up-front design--it's just that it recommends that design always proceed in the presence of code. The more effort we spend on design without feedback, the more likely that our design is incorrect. Design is done during the planning game, in addition to being done constantly throughout development. XP by no means prohibits us from sketching out UML diagrams prior to beginning an iteration, a task, or a test case. But we learn as we repeat, and our need to physically sketc diminishes as our understanding of good OO design and the system increases.

Abstractions and ideas. A body of actual code contains and includes its working existant design. They are one and cannot be separated.

I disagree with you about how well the code expresses its intent, hence the value and need to focus on OO and UML.

Quoting Ron Jeffries again:

[1] The design is treated similarly. The main place for the design to be is in the code. An Agile project is producing a number of "living documents", the most important of which is the program itself, which is produced in a growing, fully integrated form, from the beginning of the project right on until the end. [2] Working together, the team communicates design essentials through conversation supported by pictures and documents as needed.

My insertions of the numbers into Jeffries' words: [1] is essentially a restatement of what you have said; [2] is a restatement of what I have said.

I add that developer-to-developer communication and collaboration is essential for success but that it is inadequate for the customer. I also emphasise that the "supported by pictures and documents as needed" is contentious and applies equally if not more so to design as to the code.

As soon as the first line of code is written you have software. It has a design, it has functionality.

Indeed.

Any statement which lowers the supposed worth of code to "least-important" is fatally flawed in my view.

As you noted above, the code is inseparable from the design. I suggest that the design is actually a specification for the code, as is the test suite, as are the requirements; demonstrably we can implement the same design in more than one way.

The worth in monetary terms is in the contract. Okay, that is a bit cheeky! But the customer does not care about the code whatever we do. The customer cares about what it does for them.

You appear to be saying the scaffolds on the building site are more important than the building itself. Surely the entire point is to deliver a working system (working code) to a customer.

The designs and specifications are more important than the building itself is a statement I would unhesitatingly make. Any qualification would be for each stakeholder; the builder thinks the permits are more important, the subcontractors want to finish by 3pm, the kids want a backyard, Mom wants a kitchen and Dad a shed, okay, a study.