In this tweet , Simon Wardley compares making software systems explainable via moldable development (my expansion of his reference to Glamorous Toolkit) to creating maps. That sounds like a very useful metaphor to me. Many of us are interested in or even working on visual coding tools, and I wonder what their take on this metaphor is. Maps are inherently visual, but they are not the territory, i.e. the code with all the details. To me, visual tools are obviously the right choice for creating maps, but I remain unconvinced about their appropriateness for code.
I am thinking in particular of Orion Reed’s recent demo of infinite canvasses as user interfaces. For making multi-faceted maps to software systems, that looks like a very appopriate representation.
Frederick P. Brooks in No Silver Bullet seems to have a perspective on that:
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.
I’ve been struggling with this before, and still haven’t found the time to put what I said here into a more concise and readable format, but the gist is: Maps are powerful because they help us navigate… ha… I guess I should just end the sentence here… but I wanted to say… navigate multiple dimensions at once. Wardley defines maps as visualizations where position and direction have meaning, so these encode additional information in a spatial way that we are very well adapted to intuitively understand. So not everything visual qualifies as maps in his (and my) view, especially the now ubiquitous infinite canvasses rarely encode meaning in position deliberately.
That power of such representations, however, can cause us to overlook that they all are just models of a reality that has more dimensions than included in the representations we are looking at. That’s why it’s easy for Brooks to just casually list a few different visualizations we can easily create for software which all highlight and leave out different aspects of the same thing. In conclusion, as long as we are not trying to look for the one ultimate representation but accept various different ones for what they do and don’t do, it’s a magnificent tool in our toolbox.
Brooks continues saying:
In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, thus depriving the mind of some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.
From the Moldable Development perspective, the question is not "can we create maps for software systems" but "can we create mappable software systems, by making the maps as part of the design and implementation process".
A meaningful use of the directions is indeed a major challenge, and I hope that Wardley will come up with something in the course of his work with Glamorous Toolkit.
