Nature Of Order Discussion

Discussion on the NatureOfOrder

Can someone please explain how "differentiating space between [centers] and within them...from the surrounding space is progressively intensified to achieve 'contrast'" and "Roughness should occur down to 1/60 of an inch" (quoting from BradAppleton quoting JimCoplien quoting ChristopherAlexander) are fundamental properties of software design? -- TomKreitzberg

: Well it could very easily translate into choosing appropriate number and granularity of levels or "layers" of abstractions and objects in ones design. Of course the "1/60 of an inch" doesn't carry over exactly into software, we would have to figure out the corresponding measure and units. But it seems perfectly sensible to me to be able to try and measure the "distance" between two adjacent layers of abstraction (RobertMartin has one possible measure for abstractness in his book).
: If that "distance" in conceptual abstraction (or even composition or some combination thereof as in ClassUnfolding) between adjacent layers seems too large or large-grained, then it may very well correlate to some kind of ImpedanceMismatch between the two layers, and an appropriate fix would be to "add another level of indirection" directly between those to layers to provide additional interfaces / functionality / responsibility to better fit between the too-far part layers. I in fact see this sort of problem occur in practice and see it fixed in much this manner with great frequency. So while it may not seem directly about software, it's a very far ways off from being strictly touchy-feely or altogether irrelevant.

As I read it, roughness has to do with the boundaries between "centers", not the scales between layers.

You read a 3rd-hand, 2-paragraph summary of something and assumed it was restricted to that 1 thing?

I'll stipulate that there is a finite bottom layer below which software design need not be carried. But this is self-evident, and comparisons between the scale of this bottom layer and 1/60 in. are bound to be artificial. How do you define the roughness of software, and what makes it a good property?

: That's the whole point! Of course the 1/60" isn't going to map directly into something exactly in software! The point is that the concept may still be applicable, even if the exact units or ways of measuring them are different. Every single one of those "fundamental properties" may have visible 3D geometric visibility when it comes to buildings in the real world. But the things that make them preferable or valuable correspond to human needs that are not limited to buildings or 3D geometry or software; they encompass all of them.

OK, let's calibrate this puppy: 1/60 of an inch = one source statement (typically one line, in a program)

[Yes, exactly! Maybe even down to a SequencePoint as in C. This would correspond to breaking complicated expressions into intermediate steps. (cf. SelfDocumentingCode). The whole point is the make the codebase fractally comprehensible (cf. FractalComprehension). -- SunirShah]

What does this say about the appropriate size of methods, classes, and subsystems?

I say, yes we "chunk" things, but that cohesion and coupling are much more useful measures of "appropriate" method or class size than "it should be N lines/statements long". -- JeffGrigg

More cohesion is better. Less coupling is better. Cohesion and coupling being equal, shorter is better. -- RonJeffries

Right. Just my point: Direct application of the "Nature of Order" principles would imply that methods should be 4 to 10 statements long to "contribute to the beauty of the program." Most SmalltalkLanguage methods are shorter than this, so this would imply that we need to put more statements into them. Most C++ methods are longer than this, so this would imply that we need to chop them into smaller pieces. (But the Nature of Order analogy does not give guidelines on appropriate braking points.) My objection is that this "4 to 10 lines in a method to make it beautiful" is not nearly as useful as the widely accepted rules of high cohesion and low coupling make it maintainable (and as simple as possible, but no simpler ;-). While it's critically important that programs be readable (to highly trained specialists - us), it's even more important that they be functional - that they produce the correct result.

I think we have the same problem at the class level: What would you do if someone told you that all your classes should implement 4 to 10 methods; no more and no less?

What makes you think it must be exactly on the order of 4-10 statements or 4-10 methods? The NatureOfOrderDiscussion here suggests that maybe there is some level or number but that we would have to discover what it is for software. We can't guess or assume it from what that number is for architecture, only that the same concept may well apply, but that different numbers and units need to be discovered for the same underlying concepts in the different domain of software. You can't draw any valid conclusions from saying '4-10 doesn't seem to work'! -- SomeoneElse, at ctcffcp2.coulter.com

OK, maybe "a function should fit on a page" (IE: be less than 66 lines, including comments). But I still think that coupling and cohesion are more useful measures.

I would certainly agree that a program with lots of methods of widely varying sizes would not be as aesthetically pleasing to look at as one with more uniform method sizes. It just wouldn't have the same "rhythm" in presentation. However, I think that it still might be the best possible design. -- JeffGrigg

You seem insistent upon thinking that "roughness" must necessarily correspond to some specific measure rather than a property (which might or might not be easily measured). The principles of cohesion and coupling don't say anything about assigning some exact "ideal" number or even a ratio to the software in question. There are several proposed ways of trying to measure them, but most of those numbers by themselves don't mean anything; only when used relatively, in comparison against something else. And the more important thing is the principle of having high cohesion and low coupling.

I don't understand why you assume that whatever these "fifteen fundamental properties" translate to in software must somehow automatically imply some kind of absolute magic number (if indeed they translate to anything at all meaningful). And even if none of those fifteen "properties" (not numbers) correspond to any concepts we don't already know about in software, is it really so ridiculous to think that perhaps valid and valuable insight about these old and proven concepts might arise from taking a closer look at how the might seem to work together in NatureOfOrder?

Isn't it possible that something corresponding to cohesion and coupling and other known software design ideas might actually correspond to what many software designers would regard as a "beautiful" software design? Is such a consensus entirely unimaginable? (perhaps it is - but does that mean keeping a watchful, probing eye in that direction must necessarily amount to complete nonsense of futility? No one's saying you should take any of NatureOfOrder as pure gospel. Some folks are just a little too quick and too eager to discard or dismiss every last vestige of it, possibly throwing out the baby with the bathwater.

Yes, but first there should be a hint that there is a baby at all. With patterns, many people had the intuition that there were analogous patterns in building software, and that there was great value in extracting them. So far, only JimCoplien and RichardGabriel seem to have that same intuition about NatureOfOrder.

Patterns apply to functional relationships, not just to 'lines of code'. Think of a business process - organizing the client lifecycle for a product across various departmental handoffs: from sales, to installation engineers, to long-term client service. It's easy to imagine some of the rules about 'centers' and 'roughness' applying to this process in some significant way; apply them properly and every participant has a clear idea of their job, documentation is easy, exceptions are handled without fuss, and so on. Now compare your software to this business process, rather than to a building. The patterns under discussion are patterns of functional relationships and sub-relationships, not patterns of formatted code.

I try to use the "fundamental properties" to evaluate the 'Communication and Information Services' offered to the User.

In short: I identify the Business Applications as centers, the Smaller Services as centers, ... Objects as centers, ... and then I try to translate the insights from Alexander. -- PaulStubbe?

Beauty is statistical. Take 10 people all 10 may have a different opinion on what design is beautiful. So, or some of these people wrong? Is it possible to be wrong what evaluating what one thinks is beautiful?

You are merely stating a point of view that sharply contradicts what ChristopherAlexander is saying. He may or may not be wrong, but it surely is not interesting to merely contradict without supporting argument. De gustibus non est disputandum. Tastes vary. You've said nothing that wasn't said thousands of years ago. Alexander has, whether right or wrong.

Going to the heart of your opinion, however, take one million people and ask them about beauty on some subject, such as the human face. You will not get one million equi-distributed opinions. On most subjects, the results will yield a Bell Curve centered around a point of best agreement of the interviewees. I.e. your opinion has actually been tested and found false, try again. -- DougMerritt

So you are agreeing that there's no way to objectively define one design as better because the response to the design will follow a bell curve. Point proven me thinks.

Your comments do not at all track the argument I made; quite the opposite. Point not proven. The comment I responded to (which was made by you? I just signed my comment to help keep track) seemed to imply that everyone's opinion was (1) Different (2) Equally likely. I sharply contradicted both 1 and 2 by introducing the Bell Curve into this.

To put it another way, there are an infinite number of possible statistical distributions that might happen to apply to this. Only one of those says that all opinions are equally valid, and that is the one that is most strongly contradicted by studies, evidence, and me. On the contrary, I claim that there is general agreement about aesthetics in any topic whatsoever, and that it is contradicted only in the tails of the Bell Curve -- i.e. by the fringe, which always exists on any topic. -- DougMerritt

What an irony that ChristopherAlexander is on the fringe of architecture's establishment. The bell curve didn't work equally well within the architecture as a profession.

In a famous debate http://www.katarxis3.com/Alexander_Eisenman_Debate.htm, Alexander gets angry at the establishment who, in his opinion, "is fucking up the world". His promotion of a "scientific" aesthetic and appeal to the wisdom of crowds unavoidably reminds of the highest peaks of soviet culture when they condemned "reactionary" composers (like Prokofiev, Shostakovich, Khachaturian and obviously the exiled Rachmaninoff -- basically all that Russia had) because they didn't fit an equally "scientifically grounded" aesthetic. There's hardly a way to tell whether NOO is an honest inquiry, a way to get back at the said establishment who isolated him, or an honest inquiry tainted by strong personal feelings. Only history will tell. -- CostinCozianu