Make the system draw itself

A Moldable Development principle says that we should make it the responsibility of the system to provide back any depiction a human deems interesting to imagine that system.

Manual depictions about systems represent either wishes or beliefs.

They denote wishes when they describe the future system. These depictions have a role to play in software engineering as they help one communicate a goal, or to explore design options.

But as soon as the system exists, a manual depiction of that system represents what the author believes the system to be. We should not rely on them at all. Instead we should make it the responsibility of the system to show them back to us.

Take a look at this picture.

A sketch of various scenarios for the overlapping text attributes

It shows a sketch of an algorithm my colleague, Alex, works on. For an outsider, these scraps of paper might appear as random scribbles. For us, they depict interesting scenarios involving special overlapping attributes in a text editor. I say that these attributes are special in the sense that they can dynamically replace the underlying text content with something else. When we have a single such attribute, the substitution of the old and new content is straightforward. Having multiple overlapping ones is far from trivial. The sketches helped us build a mental model to guide the implication.

But as soon as the implementation existed, we made it the responsibility of the system to provide that view back to us. That's what you see in this picture.

A view of a technical object from the system showing the logic of the algorithm

It's useful to note that this visualization shows a detail from the system that would not be quite be visible externally. In this specific case, we would be able to see the result, but not the logic. Yet, if the paper sketches are useful to communicate with others about such a detail, and if the system can show them back to us through the development environment, it follows that the development experience becomes fundamental to bridging the gap between the various stakeholders of a system.

Imagine opening the development environment and having a direct conversation with a domain expert, or with a business person. What would that do for the speed of development and the discovery of interesting value?