Visual Modeling

As early as 1985, Peter Naur wrote that developing good software requires developers to have a solid theoretical model of the processes their programs must support, and that writing software is an exercise in making these mental models concrete and complete. Moreover, viewed through this lens, working software is a consequence of theory building, and the true value of software engineering lies in the rigorous formation of a shared theoretical/conceptual understanding.

Recent developments in augmented software development confirm this insight: Tools are better and faster at generating code based on theories and hypotheses than developers themselves, but when it comes to forming understanding, human guidance is (still) essential.

Then, the most important question is: How exactly do we form a shared theoretical/conceptual understanding? The answer: through collaborative modeling.

Collaborative Modeling

In software development, it is not only important that we understand how everything is put together, both on the business process side and on the software side, but all the more that we share the same understanding.

To guarantee the latter, we must make our mental models explicit and share them with each other to make gaps and differences concrete and testable. Any activity that allows us to make mental models explicit and compare them is a form of collaborative modeling.

Programming is therefore a way to model collaboratively. After all, code is the most explicit way in which we can make ideas concrete. However, code is often already too detailed for high over understanding, and too large an investment of time. The most effective way of collaborative modeling is visual modeling; drawing a complex system as a picture, together. In doing so, we must be careful to choose a representation that exposes the right differences.

Choosing the Right Representation

Mental models inherently contain a lot of dimensions. We are often not even aware of this ourselves until we have to explain our mental models.

Yet we must be able to analyze and convey our thoughts if we want to have a meaningful conversation about problem areas. Unfortunately, there is only one way to do that: by applying abstraction and highlighting the essential lessons while leaving irrelevant aspects aside.

We do this by choosing the right representation. A representation is a specific form of modeling (a UML class diagram or an entity relationship diagram, for example) which clearly displays a few dimensions and ignores the rest. Every representation we choose provides a reduced perspective on the mental model. We call the projection of our mental model in the chosen representation a ‘view’ of that model.

It is important to remember that the choice of a representation limits which aspects/dimensions of the mental model are included in the ‘view’ and which are not. Discussions about our mental model with others are necessarily limited to those aspects; we cannot test with others what we do not explicitly visualize.

A thorough analysis of our mental models therefore requires us to choose a broad set of different representations to convey different (preferably conflicting) perspectives. But which representation is the right one?

Exploratory or Explanatory Modeling

The answer to that question depends on what we are trying to achieve. Visual modeling can be used to build understanding but also to convey and teach insights.

During research, i.e., when we are discovering the essence, depth of understanding is necessary before we can distinguish essential insights from irrelevant information and identify blind spots. Therefore, we must model richly, adding many details and annotations to link disparate concepts that exist throughout our model. Our ‘views’ become detailed.

While modeling so, we may conclude that the chosen representation does not offer the right perspective for the lessons we want to make explicit. That is why we often choose multiple modeling techniques before arriving at the right perspective for deeper understanding. Since we are not looking for one type of understanding, but for multiple, exploratory modeling yields a broad set of differing ‘views’ from which new insights constantly emerge.

These kinds of ‘views’ are often challenging for others to read. The amount of detail we have to process and analyze to get to the essence is often greater than is needed to convey the essence.

When sharing knowledge, clarity of conclusions is more important than the details that led to that conclusion. Thus, we choose to model sparsely. We then use multiple perspectives to convey different ideas but keep each ‘view’ simple and minimal. Our ‘views’ are curated and reduced to a clear composition to prevent distraction from the core lessons. The chosen representations must, of course, align with our audience.

Layers of Abstraction

In both exploratory and explanatory modeling, we must keep the cognitive load low for our audience. A diagram with too many details is hard to interpret, making it difficult to recognize the central insight.

To keep the cognitive load manageable, we define levels of abstraction. Each higher level hides complexity from lower levels by summarizing them in a single component or symbol. With this, we design ‘views’ at different resolutions. Understanding the larger process requires less resolution than internalizing the details. Common terminology for these levels of abstraction is ‘macro’, ‘meso’ and ‘micro’ for high-over, intermediate, and low-level detail, respectively, though we can introduce as many levels as is convenient.

Conclusion

In short, visual and collaborative modeling is the essential method that enables us to create the shared theoretical understanding needed for valuable software.

By making mental models explicit and testing them, we reveal and discover the essence of the problem and master complexity. By doing this together with domain experts, we anchor the ‘validated learning loop’ in our work and internalize a theory of the problem area.

Choosing the right representations for our mental models, distinguishing between exploratory and explanatory modeling, and implementing layers of abstraction are the best tools for effectively achieving shared understanding as a team.