__Textual modelling VS visual.__ Have you ever come across infographics that are not just pictures but truly provide a comprehensive understanding of the system being modeled? 🤔 The kind of representation that’s easy to edit, maintain, and upgrade, and that a new engineer on the team can grasp without any huge additional explanations or clarifications from more experienced colleagues — and __without__ formal text additions. Personally, I’ve never encountered such diagrams. In fact, I believe it’s probably impossible to create them. What I have seen are either poorly designed, ugly, and confusing diagrams or very beautiful and impressive visuals that evoke a good first gasp but quickly lead to a choke. 😶 These pictures may capture your admiration for 10 minutes, but as soon as you dive deeper, they raise a bunch of questions. Questions that can only be expressed in text to be properly addressed and further processed. Text carries far more meaning per unit of space than a picture, and it’s much easier to correct and expand. A picture, on the other hand, can only be redrawn. Take, for example, a flowchart representing a loop versus just the word “loop” itself. Both convey the same meaning, especially to someone who already knows what a loop is. You might argue that a flowchart makes it easier to explain the concept of a loop to someone with no programming background. But that’s not true. 🙅‍♂️ Show a passerby a flowchart of a loop without annotations — they likely won’t understand a thing and will fall into fantasies and assumptions, depending on their background. However, a concise text description of a loop, with a couple of examples and analogies, can communicate the concept to __almost anyone.__ From that moment on, the word “loop” will carry the same meaning for them as the clunky, angular flowchart with all its blocks, enabling its use to explain more complex matters. The word becomes a powerful container of essential meaning, staying flexible and applicable. This is a simple example, but it extends seamlessly to diagrams and models of any size and nature — from the smallest to the largest. The bigger the system, the more relevant our problem becomes. Imagine a large system and the challenge of modeling its concepts and domain entities using both pictures and text. The latter approach feels promising and applicable. Whether it involves formal natural language specifications or specifications through common programming languages, it remains, ultimately, just text. However, it is obviously not easy to reflect all domain intricacies in the code itself. That’s the point I was referring to here 🔗 Formal textual specifications are easy to write. I mean, even if it requires a lot o mental efforts of course, it is easier to reflect in text, than in rock painting. Because text carry more meaning in any sense, be the end of the day - even per square centimeter, and they are much easier to work with and moving forward. We can even write multiple versions of the same system specifications for different stakeholders, using their “native languages.” Good luck doing that with pictures. You will end up redrawing them constantly or struggling to find a way to communicate with others and share knowledge, instead of doing actual work. Systems thinking and engineering are collaborative efforts. A picture alone does not effectively transfer domain-specific information from one person to another. Textual specifications excel at this. Domain-specific languages are built from textual entities, not emojis. It feels to me that there’s really nothing to argue about 😞