Cut the Links Until You Get to Hierarchy
“If the button is not shaped like the thought, the thought will end up shaped like the button.”—Ted Nelson
I’d like to share with you a section from the famous book on software creation (and creation generally): The Mythical Man Month, by Fredrick Brooks. Why? This particular section is a proud example of our habit, as a species, of letting our tools dampen and simplify our thinking, rather than taking the time to build tools that are ideisomorphic—that is, sensitive enough to represent human thought—or even to build tools that actually expand the compass of cognition.
Fundamentally, I see The Mythical Man Month as an excellent work, well-written, and completely deserving of its status as a classic. Brooks just makes different assumptions and has a different reading list, which makes an excellent book, at times, absolutely shocking to me personally.
Cut the Links Until You Get to Hierarchy
Here is an offending paragraph:
The reality of software is not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs, superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These are usually not even planar, much less hierarchical. Indeed, one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more of the graphs becomes hierarchical.
Let’s start by contextualizing and explaining the passage to anyone not fully familiar:
One: This is part of Brook’s essay (later published as part of The Mythical Man Month), called “No Silver Bullet.” In this essay he outlines how he believes that, at that time, there could be no single innovation that would offer software creators an order of magnitude (10x) increase in speed, during the 10 years following the essay’s publication.
Brook’s reasoning is that, by that time, the main time-suck for development was not “accidental” complexity, that is, complexity that is contingent on the methods and techniques of coding and implementation, but rather “essential” complexity: that of the actual abstract structure of the program, it’s parts and how they work together.
Two: He notes that one reason why essential complexity is so tricky, is that it is very hard to communicate the real, complete structure of a program. “The reality of software is not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics.”
This is to say that one can sort of represent, real-world city streets on a two dimensional map, inasmuch as such terrain manifests on the twoish-dimensional surface of or world (allowing for the occasional bridge or tunnel). But software is harder.
Three: Software is not two-dimensional, like the surface of paper, it is n-dimensional; processes in our software diagram can be connected in any way. So, as Brooks notes: “As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs, superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These are usually not even planar, much less hierarchical.”
For those not familiar with the terminology, a “graph” in this context refers to a mathematical construct consisting of nodes (e.g. each member of your friend group) and edges (e.g. the relationships between them), quite like “mind maps.” Planar graphs are those for which the edges to not cross, which makes them easier to read; hierarchical graphs (if I read correctly) are those that (in layman’s terms) resemble trees, not unlike the famous corporate org chart.
Four: Because anything can connect to anything, things get very hard to draw and visualize. In Midtown Manhattan, say, it’s safe to assume that the intersection of 9th avenue and 47th street is connected to four other intersections: two along 9th Avenue, two along 47th. But, imagine if that single intersection could connect, legitimately, to any other intersection in town, easily and without limit. If this is getting hard to visualize, that’s Brooks’ point.
Five: And Brooks casually concludes: “Indeed, one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more of the graphs becomes hierarchical.”
And I say no, no, no!
No!
To close the loop here, Brooks is saying that if one is trying to visualize the conceptual structure of a computer program or system, one should deliberately delete the visualizations of connections between elements until it represents something hierarchical like a corporate org chart. This is despite the fact that each time we cut a link, our picture lost information and became became less true.
The fact that this was to him an acceptable policy seems to originate in our species’ odd relationship with hierarchy and linearity: with our fear of that which is non-linear and non-hierarchical, and our habit of banging our head against the invisible ceiling that separates two-dimensional constructs from those in three and more dimensions.
These are almost the same problem: we permit the org chart because it is two dimensional (one for rank, one for department). Ironically, I should think that most people who have worked in a company that claims to have such a chart know it to be fictitious: many employees have relationships with more than one manager and take multiple directions, employees obey others who are de jure their equals all the time, to say nothing of behind-the-scenes relationships that look more like friendships than command structures.
I’m here to tell you that multidimensionality is to be desired: the best of life and our creations have this property. Hierarchy should only be created or enforced when it is actually useful or necessary, which is less often than most people think.
Some examples:
Hierarchy
Since Unix in the 70s and (so far as I know, universally thereafter) the way we organize media on our computers is hierarchical: files in folders, folders in other folders, all of which resides in one super folder; one file or folder can sortof be in more than one folder at once, but the OSs make it hard, intuitive and fragile.
This is absurd and divorced from reality: why must I put a digital construct, which can be associated with and therefore contained within any number of folders, in just one? This is like claiming that Bach is either a harpsichord player or a composer, not both, or that saying that he is more than one thing is odd or unusual. (Yes, if you’re wondering, I reject the entire file/folder/“file system” fiction, too, but that’s a discussion for another day.)
Linearity
Physical books are lovely, but one of their most meaningful limitations is the extent to which they force linearity: chapters, paragraphs, sentences, etc. must follow one after the other, whether or not each one actually follows from that which precedes it. I often find myself writing an article in which a given heading contains a few points, equal in importance and order, but am forced to start somewhere: this section is such an example, there’s no reason that hierarchy should come first, but something had to.
The Web is a patronizing circus compared to what hypertext could have been (and will be, if people like me have our way), but at least it gives us the ability to make arbitrary jumps to other material. Wikipedia, for example, is non-linear in this regard: any article has tens, hundreds, even thousands of jumps to other articles and websites, from the intersection at 9th Avenue and 47th Street in Manhattan to Holloway Road in London, so to speak.
If you actually mapped all these links and visualized them in a diagram, Books would faint at seeing uncountable, densely-linked “general directed graphs, superimposed one upon another.” But it works, and this is not something perverse, degenerate or unmanageable: we do it all the time, and it is a crude hint at the actual structure of human information systems.
If you want more on these ideas and concepts, see Ted Nelson’s work, excellently exemplified by his TED talk here:
We Need Better Tools
Indeed, our tools are lacking in his regard, and we’re subject to a cycling Conway’s law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
We build hierarchical organizations, which build restrictive, hierarchical, two-dimensional software (conventional word processors, spreadsheets, relational databases) which makes us think hierarchically and build more hierarchical organizations, and then we do it all again.
Brooks references something like this, except not by name and totally neutrally, in one of his follow on essays tacked onto later additions of the book. One of his most important messages is that people and companies should buy software off the shelf rather than building it themselves, where possible. He noted that the biggest objection to this idea when he first expressed it was that off-the-shelf tools aren’t flexible enough to conform to a company’s business systems; but, upon finishing the later edition, he noted that people just bought the software and changed their systems to match it.
I would never claim that a company’s existing systems are always better than the software designed to serve that function, I just wish that Brooks had recommended a little caution: if it’s that easy to make us change our lives to conform to software, the dictator might then shun the power government and prefer instead to run a technology company; or, perhaps, a technology company director might accidentally become the dictator.
And we seem to be helpless. It makes me want to tear the needle off the record (making that satisfying screech) and say “Enough! Snap out of it! Our species needs better tools, and I demand we make them!”
Indeed, this approach is discussed many times by Brooks: high-level programming languages, special development team structures, etc., but never in the actual means of storing and representing of information. Perhaps it feels too trivial. He even spends a few paragraphs talking about the limitations of flow charts, the difficulty in reading one printed across several pages, but never asks for a system that lets the user create, modify and share arbitrarily connected graph structures. Surely that would be at least a little helpful.
Thus, dear reader, we are like the people of planet Krikkit in The Hitchhiker’s Guide to the Galaxy, who never even ask whether they are alone in the universe, their sky obscured by dust at night and by blinding sun during the day: “It’s as if they had a blind spot which extended 180 degrees from horizon to horizon.” Our response to any tool that puts us in this sort of position with forced hierarchy and linearity, and by destroying information, ought to begin with an interjection, followed by a declarative and an interrogative: No. Non serviam. Why?
