I've put Popper aside for a while to read a book I received in the mail the other day, Kevin Lynch's The Image of the City, which after the first twenty pages looks very promising. I've had this book on my list ever since I read The Death and Life of Great American Cities by Jane Jacobs, and my interest has only gained since then, particularly after reading what Matt Webb has written about it.

When I read Jacobs's book I tried to apply her ideas to software architecture and development.¹ City planning seems like a good metaphor for software architecture, and it's alreadyused within the field of enterprise architecture. So far, Lynch's book seems to do a good job at clarifying the ways in which this metaphor is relevant.

Lynch introduces the concept of imageability, which he defines as

that quality in a physical object which gives it a high probability of evoking a strong image in any given observer. It is that shape, color, or arrangement which facilitates the making of vividly identified, powerfully structured, highly useful mental images of the environment. It might also be called legibility, or perhaps visibility in a heightened sense, where objects are not only able to be seen, but are presented sharply to their senses.

The corresponding for (the internals of) software would be how well its source code, when explored by someone new to it, evokes a mental picture of its entirety. I thought about this nearly a year ago, but couldn't express it well. And since then I've realized that it has to do with more than code.

In a project I once was in, the architecture was frequently drawn on the white board and explained to various people. I had some problems with some of the decisions behind the architecture, and questioned them, but overall it was okay. As an idea. The biggest problem was that the architecture as explained in meetings was nowhere to be found in code. Well, there were packages and classes mapping to its concepts, but its principles were violated everywhere. Even the architectural decisions I questioned, and which the architect fiercely defended, were invalidated by violations in the code. An architecture emasculated.

This situation can be explained as the architect having one image of the system, and the system had low imageability, so the images evoked in the minds of others were too different from the intended image, as is obvious by the sheer number of violations of the architecture.

Viewed this way, the work of the architect becomes a process of creating an image of the system, then creating a system with high imageability, with a high probability of evoking images as near the original image in the mind of the architect.

¹ See my summaries for March and April last year for posts on The Death and Life of Great American Cities and software architecture.