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.

can you please point me to that demo of Orion? I can not find it

thanks!

Also https://m.youtube.com/watch?v=csGNVaB83Rk&pp=ygUXVG9vbHMgZm9yIHRob2lnaHIgcm9ja3M%3D

nice, thanks a lot!

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 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.

@Stefan thoroughly agreed with Brooks there — it's something I could have been more explicit about in my recent stuff on canvases as an HCI substrate, as the argument is not that software/computing has any canonical visual representation (especially not one that's planar, as in the graphs example) but that we can take the very high-dimensional and heterogenous structure of software/programs/systems/protocols/etc and provide richer ways for these to be mapped from many partial perspectives, which can give rise to legibility in the same way that maps and language make our complex real world legible (as @Konrad Hinsen pointed to with the Moldable Development approach) The barriers to creating diverse representations leads to us over-indexing on too few perspectives. I think we need much more heterogeneity coupled with an ability to morph between representations (maps of/between maps) that's far greater than what we have today, if we are to dispel the myth that any one of these is the whole picture. ^ this means, to me at least, significant shifts in production and productive processes, analogous to the shift in literacy (or the way that productive forces reshaped physical goods as Marx observed)