In a study that was published at MoDELS conference in 2018 [1], I reported the results of observing the development efforts of two Software Engineering projects that used Model-based approaches to develop software for two self-driving rovers. I found that most of the effort is spent on collaboration and communication between developers. When it comes to communication, we all know that its quality in Software Engineering projects matters and has a huge impact on the development process and outcome. The quality of commination in Software Engineering is influenced by different factors: human-related (e.g., cognitive, social, and psychological factors), organization-related (flat vs. hierarchical organization), team composition and dynamics, artifacts used in the process (such as communication tools and documentation), etc.

In this post, I want to share some interesting findings from studying the effect of artifacts on development communication. In particular, the impact of software design representation on software design communication. Graphical representations, such as software models, encode and present knowledge differently from textual representations. In particular, they provide a visuospatial representation of information, and can recraft this information into a multitude of forms by using fundamental graphical elements, such as dots and lines, nodes and links [2]. Also, it is known that graphical and textual knowledge representations are differently processed by the human mind.

To understand the effect of graphical vs. textual software design representations on design communication, I coordinated a family of experiments in collaboration with several researchers from four universities in Europe. The experiments are inspired by the Telephone game (or Chinese Whispers) and involved 120 pairs with a total of 240 participants (See Figure 1). In each randomly formed pair, one participant is randomly appointed as a knowledge explainer and the other one as a knowledge receiver. The participants were asked to give some information about their design knowledge and experience. The knowledge explainers were given a graphical or textual software design describing a MVC design of a software application. The explainers were given 20 minutes to read, understand, and master the design. After that, the explainers had to communicate or explain the design to the receivers in 12 minutes—- using the design artifact. The discussion between the participants was audio-recorded. Finally, the design artifacts (graphical or textual) were taken from the explainers and all the explainers and receivers were invited to answer some questions on the design artifact and the communication experience.

Software Engineering Whispers experiment

Fig 1. Software Engineering Whispers: Experimental Design

The results of this family of experiments will be soon published by the Empirical Software Engineering journal (pre-print).

In the following, I summarize the main findings of this family of experiments and discuss some impacts on practitioners.

The first interesting empirical findings is that the users of graphical software design representations had more active discussions about the design than the users of the textual design representations. I mean by active discussions those in which the discussants actively question, inform, and motivate each other. Active discussions increase the quality of communication by contributing to the effectiveness of communication.

Second, we empirically found that graphical design representations support the recall of design details. In other words, the participants who used the graphical artifact during the discussion were able to remember more details about the design than those who used the textual artifact. Certainly, recalling the details of a discussion or the artifacts that were used during that discussion reduces the number of miscommunications, which in turn increases the productivity of the team and ultimately contributes to the satisfaction of stakeholders.

Third, while analyzing the recorded, and further transcribed, discussions between the explainers and receivers, we interestingly observed a difference in the explaining approach between the explainers of the graphical vs. textual artifact. Figure 2 provides an illustration of the observed explaining approaches.

The Explaining Approach of Textual vs. Graphical Software Design Explainers

Fig 2. The Explaining Approach of Textual vs. Graphical Software Design Explainers

On the one hand, the explainers of the textual artifact tended to explain the three modules of the MVC design sequentially: Firstly the model entities, then the controllers, and lastly the views, as these modules are orderly presented in the textual document. This trend is intrinsically imposed by the nature of textual representations where the knowledge is presented sequentially on a number of consecutive ordered pages. On the other hand, the explainers of the graphical design had more freedom in explaining the design. Indeed, according to their explaining preferences, the explainers of the graphical artifact tended to jump back and forth between the three MVC modules when explaining the design. Based on this, it seems that a graphical software design representation has an advantage over the textual representation in unleashing explainers’ expressiveness when explaining the design, as well as in helping navigation and getting a better overview of the design.

Based on the previous findings, I provide the following impacts on practitioners:

  • Agile development practices include several processes in which communication is at least involved, if not central. Daily meetings are, by definition, the perfect example of agile ceremony which completely relies on communication. Holding daily meetings as a mechanism for design problem solving has positive effects on the communication of the design issues. Accordingly, introducing graphical software design in daily discussions about design decisions would enhance the communication quality between participants, which in turn could strengthen the impact of applying agile practices in software engineering projects.
  • Communication is one of the most time-consuming tasks in software development, requiring more effort than any other development activity. The use of graphical software design as a support for design-related communication could be of benefit for productivity. Moreover, minimizing the required effort for communication would provide developers with more time at disposal as well as reduce developers mental load, so they can focus on different tasks.
  • By observing the explaining approaches of the explainers of graphical vs. textual software design representants, it seems that the graphical design representing has an advantage over the textual representation in helping navigation and getting a better overview of the design. Even though this requires more investigation, I suggest that, due to its nature, a graphical design provides more adaptability and extra degrees of explaining freedom, which makes it a better pedagogical medium for face-to-face design knowledge transfer.

Now that you have read this post, you can safely state that a picture is indeed worth a thousand words!.


[1] Jolak, R., Ho-Quang, T., Chaudron, M.R.V., & Schiffelers, R.R. “Model-based software engineering: A multiple-case study on challenges and development efforts”. In Proceedings of the 21th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems, pp. 213-223), 2018.

[2] Tversky, B. “Multiple models. In the mind and in the world”. Historical Social Re-search/Historische Sozialforschung. Supplement (31), 59–65, 2018.

Interested in modeling?

Interested in modeling?

Follow the latest news on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This