Noo Has Nothing To Do With Software

I'll go out on a limb and say, based on my reading of the NatureOfOrderTalkAtChicago, that the NatureOfOrder has nothing to contribute to the design and implementation of software. Talk all you like about wholeness and centers, the Void and inner calm, but software is not a three-dimensional structure. It's a sequence of zeros and ones, and pretending it's anything else is a dubious exercise at best.

So is pretending it's nothing but zeros and ones - but that's a different story ;-)

Well, let me amend my prediction: whatever contribution the NatureOfOrder might make to software design will be fortuitous and accidental, the product of bright minds influenced by Alexander's work but focused on software; it won't form the basis of a grand unified theorem of software, and any attempt to make it is doomed from the start. -- TomKreitzberg

Isn't that true of just about anything? I think most things involved with the process of designing any kind of large structure have some important things to teach us, even if they are only three-dimensional. Acerbic predictions aside, I certainly don't claim to know how many dimensions software has, but I think I know something about the number of dimensions in the world perceived by the folks that create it. And that's always going to have a big impact on whatever those people create (and how they create it, and how they decide it is good). As for what impact NatureOfOrder will have, only time will tell. I certainly won't presume to attempt a guess (I wouldn't have guessed it for APL or TTWOB 20 years ago either. :-)

Now that's another question: What impact has APL or TTWOB had on software? I grant that Alexander's taxonomy has proven useful, giving a structure to capture knowledge that the software development community desperately needs to have captured. I'm skeptical, though, about what the TouchieFeelie? aspects of his theories have to offer. The QualityWithoutaName is fun to talk about, but I'm not convinced it's any more (or less) meaningful than speaking of the aji of a design (to steal a term from go) - or, for that matter, of its entropy (to steal a term from thermodynamics).

Software development is a field in search of a metaphor. Or rather, it's a field crammed with metaphors, and searching for more. Architecture is a dominant metaphor right now (and if I read one more sentence by GradyBooch about building a dog house, I'll spit), but ItsOnlyaMetaphor.

But software need NOT be beautiful. It must be functional.

: (some would argue you can't separate the two)

I find it exciting and interesting that Alexander has found a way to quantify, objectively measure, and test "beauty". But I also find it irrelevant to software development. -- JeffGrigg

: (On the other hand, some would say that BeautyIsOurBusiness.)

I imagine this only illustrates that summarizing an interesting concept can make it sound like uninteresting error, but I was especially struck by this statement on NatureOfOrder: "Alexander maintains that most people will usually choose a given design over its lesser counterpart, and that the choice is experimentally objective."

This seems either tautologically true (if you define "A is lesser than B" as "most people choose B over A"), or obviously false (if it's a claim that given any set of designs, even a set of cardinality greater than two, most people will agree on which one is the best).

I think it may in fact be less false in programming than it is in architecture, perhaps only because there are more, and more different, people who would have an opinion about a building design than there are people who would understand programming well enough to have an opinion about a program design.

Certainly there are consensus principles, in that mostly every practitioner of programming/architecture would recognize certain things as mistakes. But once some designs avoid all the obvious errors, it seems to me there is then room for disagreement among the competent as to which one is "best". Alexander can claim to have discovered some new things worthy of becoming consensus principles; that's how a field progresses. But he can hardly claim to have discovered that given any pair of designs, he can "objectively" say which one is better. At least he can't claim that if he wants to be taken seriously!

I favor the notion that there are better and worse "distances" between layers of software, and that the distances should be more or less uniform across layers. But I believed that before I read that Alexander claims to have discovered the fifteen fundamental properties of wholeness and life. And I believe that attempts to distill useful metaphors from his new work will get bogged down in metaphysical cul-de-sacs that will not arise in exploring other things involved with the process of designing any kind of large structure. -- TomKreitzberg

: The big question is how, if at all, would this manifest itself and be observable in the context of software? Just because the 1/60" measurement doesn't translate by no means implies that "roughness" or the other properties have no merit in software. Maybe they do, and maybe they don't. Excluding them "up front" is no less ridiculous than blindly assuming them to be axiomatically correct. Either extreme is sheer rubbish in this case. There are very clear aspects in each one of them that seem to have at least some relation to similar things in software. Asking ourselves how or if they might extrapolate to software, and if so how do we observe it, is certainly a valid question; Taking a deep look for answers (rather than discarding them with belittling dismissal) is an equally valid pursuit. If it doesn't help you - fine. That doesn't mean others won't find it useful.
: Alexander's experiments were conducted by collating the observations of lots and lots of different people. So he clearly wasn't claiming to have been the first to see all of these things. If anything, he's suggesting that these ideas and beliefs have been present in most people in most cultures throughout history. He's merely reflecting a bit more than most, attempting to see if he can flesh them out and articulate them and relate them together at a more fundamental level. The fact that you've held such ideas about "better and worse distances" would tend to support rather than refute his hypothesis. Of course, one still needs to figure out what these things look like in the world of software. That we don't know the answers yet doesn't mean that seeking to learn them is a fool's errand. Only that we don't yet know.
: Attempts to distill useful metaphors from just about anything are likely to get bogged down in metaphysical cul-de-sacs, regardless of whether or not any good may come of it. That doesn't disprove the value of anything, nor does it invalidate anything. Patterns are a perfect example. There is a great deal of metaphysical metadiscourse on the topic that seems like so much mumbo-jumbo. And yet, despite all of that, there is a great deal about patterns that has indeed been immensely helpful and useful.
: NatureOfOrder is unlikely to be significantly different in that respect. Parts of it will likely turn out to be worthwhile; others will likely turn out to be worthless. But it's highly unlikely that 100% of it is crap nor that 100% of it is "golden." It doesn't have to be all or nothing. Some prefer to close-off their minds from seeing any possibility of utility; others prefer to forge ahead with an open mind, keep what seems useful, and leave the rest behind.

Rugs are different than programs: A most highly functional rug would be mottled grey/brown. Such a rug would be less expensive to produce, and would hide dirt and wear better than a rug with complex geometric designs in contrasting colors. (...spoken by a man with a Turkish rug mousepad, and imported rugs and blankets covering every open space in his home. Aren't I a contradiction? ;-) -- JeffGrigg

How do you apply these principles to software? I look at a class diagram, or an entity-relational diagram, and I don't see these archetypal centers emerging. Maybe in deployment I see them ... but now what? Patterns are prescriptive; where's the prescriptive component of NOO? Of course I'm going by some notes on a summary lecture of what is reportedly a vast work, but still, to tell the truth, it sounds to me mostly like a restatement of Wright's OrganicArchitecture. -- PeterMerel

See CentersInSoftware

(My first words on this incredible web site - please be patient with my Frenchy English) I deeply agree with TomKreitzberg's and JeffGrigg's remarks. Computer scientists or engineers (I'm one of them) often feel amputated from something essential in the NatureOfOrder.

Software patterns are NOT "deeply embedded in our cultures throughout much of the history of civilization" (quoted from BradAppleton's notes of JimCoplien's talk) as other kinds of patterns (in architecture, painting, music, literature, poetry, etc.) are.

I disagree. Anyone who has worked briefly with an expert carpenter and pays attention will learn very quickly that a mastery of sequences is the difference between the expert and the amateur. Example: The wood here has such and such a grain and is placed in such and such an orientation, place it first to temporarily bear the weight of the crosspiece, (but in this case only if the crosspiece is connected to the stone foundation), then fasten in a certain way, then go back and add the second connecting piece of the other kind of wood to the junction with the stone foundation. If all these sequences are done properly, all the materials will not only be fastened correctly but will respond as a unit to changes in humidity and the effect of settling over time. But compare this, the amateur lines up the components and fastens them all; when he is done the structure stands and is sturdy, but over time is not as durable. This is Alexander's example, actually: there are perhaps eight decisions made and some simple activities of nailing and fastening which are within the ability of the beginner, so the expertise is invisible. Alexander points out that in this case, we must understand that the sequence of decisions is the single correct choice from (8)!factorial possible sequences, and that the entire process of construction is a sequence of sequences. Furthermore, all human technology can be understood as the mastery of appropriate sequences. Once this is done, software patterns can be understood as a sub-set of the human technical propensity to master sequences.

On the contrary, software engineering promotes a radical departure from the human nature and from its deep embodiment. The fact that so many people feel very uncomfortable with the computer culture is a strong argument to that claim. Another testimony is the ArtificialIntelligence failure to mimic the human way of thinking and learning. Please refer to works by HubertDreyfus and TerryWinograd for a deep analysis of that failure.

Basically, they both say that software lacks and WILL ALWAYS lack of an essential ingredient for understanding : embodiment. Our common sense tells us that beauty, emotion, comfortableness and understanding primarily involve our body and the whole history of our body throughout ages. And, for still a long time, software is bodyless.

At some point we have to choose between correctness and truth. And truth without a body as a corner stone is just nonsense. That's a lesson from philosophers such as LudwigWittgenstein (from the "Tractactus logico-philosophicus" to "Philosophical investigations") and MichelSerres ("Les cinq sens", "Le passage du Nord-Ouest", "Statues", etc.). -- JeanMichelAndre

"I think too many folks are trying to interpret this NOO stuff way too literally w.r.t. software. It's an idea to investigate, not some directive to obey. Some folks seem to be heatedly affirming that NOO is not a [software] holy grail. That's fine. No one ever said it was."

Well, some people do. See for example Nikos Salingaros's web page at http://www.math.utsa.edu/sphere/salingar/NatureofOrder.html. I could not resist to quote him, quoting himself: "My personal opinion is that this book will be recognized as one of the twentieth century's most important documents. Although I am admittedly biased, the same opinion is expressed by those who have had a chance to read copies of earlier drafts."

Nikos Salingaros, Professor of Mathematics, San Antonio Texas.

And others are speaking of "one of the most consequential works Oxford has published in all its 500 years". And they are not kidding ...

: Umm - but neither of the above quotes mention anything about software! They certainly weren't written with software in mind. They might be calling it a "holy grail" w.r.t. to something, but certainly not software.

"There's something potentially interesting there, and someone needs to look at it a lot further to show how & where it might have elements that are applicable to software. That's all. No more and no less. So what are people arguing about? (and, more importantly, why? If I didn't know better I'd swear some folks here seem somehow threatened by it. I don't understand it)."

I'll try to explain why I post my own comment. It's challenging to me. Thanks for giving me this opportunity.

I'm interested in metaphors. What is it exactly? How do they emerge, live and sometimes die? How does is work? It's not part of my job - at least no more since the so-called AI winter - but it's a recurrent question in my mind. And besides, I'm a programmer and not afraid to be one ;-). I'm just asking for the right to think about my job, from time to time. Still a word about my background: I am one of those DouglasHofstadter's "GoedelEscherBach" 's admirer.

With this pattern story, we have a living metaphor to observe and it's very exciting. I found interesting to question the grounding (?) of this metaphor, as TomKreitzberg and JeffGrigg did it before me. Is this metaphor really working and is there a potentiality to find something else in the coming NatureOfOrder book or is it just a loosy word game around architecture, patterns, etc?

The sentence I've quoted above from BradAppleton's notes of JimCoplien's talk about NOO let me think that what is behind Alexander's ideas of "pattern", "quality", "beauty" can only be very loosely apply to software.

As far as pattern is concerned, this concept could have been imported from many other domains and authors, amongst them are FerdinandDeSaussure in the field of linguistics, GregoryBateson, MargaretMead? and ClaudeLeviStrauss? in the field of anthropology, JacquesLacan? in the field of psychoanalysis, etc. Structuralism is the name of this century-old approach. Anyway, if Alexander's books have been a source of inspiration to the pattern community (and as a Java programmer, I appreciate the neat structure of the AWT class library, for example), I have to recognize that something has worked there.

As far as quality and beauty are concerned, I claim that since software programming is a bodyless activity, it cannot vehicle feelings, emotions and beauty as human arts (architecture, literature, etc.) do.

But I don't think I've written the last words on that matter. I'm ready to discuss counter-arguments if there are some.

-- JeanMichelAndre

I think that we have enough material from and about Alexander by now to have the right to ask some questions about the pertinence of this methaphor and to get insights if it is worth buying and reading the coming four (!) volumes of NOO in the expectation of some guidance in our software engineering practices. I rather think that that's you and the anonymous contradictor above that are very quick to try to disqualify our questions.

I agree that there is a baby somewhere - and the java class library structure is one of the good thing that this baby has already been able to produce, not so bad for a baby! I just question the grounding and the deepness of the metaphor. Maybe we have to find insights for the software engineering by ALSO examining why this metaphor does not perfectly work.

Actually the whole quotation from your notes is:

"Alexander states that the patterns of these kinds of beauty were already in our heads and were deeply embedded within our cultures throughout much of the previous history of civilization, but that we forgot these things as we evolved toward cultures that were more technically-oriented and became separated into more specialized disciplines and groups, rather than more eclectic, cross-functional ones."

We have to think about it, because we - as computer professionals - are deeply involved in this ever more technical and schizophrenic orientation of our lives. -- JeanMichelAndre

"I think that we have enough material from and about Alexander by now..."

I rather doubt it. Maybe for some of the patterns stuff, but not likely for NOO. Since the books aren't available yet, all we have are some notes I took, and a few slides or pages from other people (like RichardGabriel, JimCoplien, NikosSalingaros). That's hardly "enough material" to start making the kinds of conclusions we've seen here. A lot more questions need to be asked (and answered first).

"and to get insights if it is worth buying and reading ..."

Who said you have to run out and buy it and read it? Salingaros perhaps, but he wasn't speaking directly about software. No one's saying you have to rush out and purchase it. Only that here's the next "stuff" from the guy we got lots of patterns material from. Since we were able to extract some software relevant stuff from that, maybe, just maybe, we might be able to figure some out here too. But its up to us to see where and what (if any) that relevance might be. That means people who are interested should take a pick at the info they can find (without being forced to run to the bookstore, especially since its not available yet) and pose thoughts and questions about what those things might be. But I don't see too many people doing that here; I mostly just see people passing judgement before any of that's been done (instead of asking questions that might flesh some of it out).

"I rather think that that's you and the anonymous contradictor above that are very quick to try to disqualify our questions."

Not in the slightest. Im not disqualifying any questions at all. In fact Im encouraging them. But asking questions is very different from quickly passing summary judgement before the questions and ideas have been posed (much less answered). [I don't think the "anonymous contradictor" is contradicting anything either. I Think he/she is questioning the basis of some assumptions people seem to be making them. In fact, whoever that person is seems to be asking more questions than many of the other contributors here.]

"I just question the grounding and the deepness of the metaphor."

That's GREAT! Go right ahead and ask your questions! Questions are good. (answers are even better. :-) No-one is saying don't ask questions, and no-one is trying to disqualify such questions (honest). What they are saying is to reserve judgement (not inquiries) until a lot more of these questions have been asked. Asking how property XYZ relates to software is splendid! Then maybe we'll see some possible ideas and can give constructive criticism. But saying "XYZ is wrong" or "XYZ has no relation to software" is most assuredly premature right now. So is saying "this metaphor does not perfectly work" when it clearly has not yet been adequately explored. Feel free to ask question that might lead to answers that would explain how all or part of this metaphor might work (or not). But don't declare it to "not work" just because we don't know yet. (Many here know Im rather fond of saying AbsenceOfEvidenceIsNotEvidenceOfAbsence. :-) If you think you do know, then please enlighten the rest of us (cuz if you do, you clearly know more than I about NOO, and I've read through the drafts. :-)

In the meantime, less conclusion-assuming (not just about NOO, but about whether or not someone is saying "stop chatting, start coding", or discouraging questions, or contradicting people) should probably give way to more question-asking. If we're unsure, or we don't know, or we don't see it, then ask rather than declaring outright.

Perhaps some of the bold, negative predictions at the beginning of the page weren't very effective at getting this page off to a constructive (rather than destructive) start. Who has a specific question about how a specific "NOO property" might or might not relate to software? By all means, please ask it! And anyone who wants to contribute some candidate possibilities, please do so. We anxiously await you. -- BradAppleton

Another way of considering this discussion about NOO & Software is to reverse the question: what does software have to do with the Nature of Order (in Architecture) or indeed THE NATURE OF ORDER (of the world/universe?!)

As far as Architecture is concerned there have been any number of folk (theorists/teachers/usually non-practitioners) in the last few decades who have sought to re-define architectural theory by relation to other disciplines, eg linguistics, politics, psychology, gender studies, perception theories etc.

Sometimes interesting reflections on architecture do crop up amid the deluge of papers, books & lectures that usually result. However it appears to me, as a practitioner and teacher, that the enthusiasm usually shown to the 'new way of seeing' all to easily results in the main plot being lost.

Somehow, I think it's important to re-assess just what the core issues of architecture are and which (outside) disciplines actually/really/reasonably have something to say about these core issues.

Is this last comment relevant to this discussion re software?

-- MartinNoutch

It could well be Martin. Software has had trouble (some of us at least feel) identifying what its core issues are. Try NewAnalogiesForSoftware and WhyNewAnalogiesForSoftware (if it's possible for a non-software person to do so without DisciplineEnvy turning to CrossDisciplineTedium?).

Computer scientists or engineers (I'm one of them) often feel amputated from something essential in the NatureOfOrder. JeanMichelAndre

I agree (in SoftwarePatternsArentAlexanderPatterns) with Jean Michel here. But I don't agree it has to be this way, or that software has to be disconnected from human life or embodiment, any more than buildings do.

The main problem is that the software world has not gotten close to being able to address or relate to the issues Alexander does.

It's a much smaller problem that NatureOfOrder will be even harder for us computer people to distill into something technical and abstract than APatternLanguage was.

Interesting line of discussion - one thought that comes to mind... What if NOO's relationship to software is a bit less direct, and maybe even indicative of a sort of inversion. Kind of like, maybe part of what makes software distinctive is exactly that it _doesn't_ reflect the natural order as most everything else seems to...