A Common and Expressive Language on Remote Teams

Introduction

They looked human and spoke the same language. However, there was no understanding in our conversation. They didn’t understand each other so I discarded I was the only reason. They used different words to refer to the same concepts so reasoning in the same direction was impossible. I constantly had to act as an interpreter so that two of them could communicate. It was a tedious task and I didn’t know if there was a loss of semantics in my interpretation. The previous storytelling could well be from a fiction novel. Instead this situation is what I had daily with my team during technical conversations. If you feel identified with this situation, then you have the same problem as I did. You’ll be interested to know how I’m solving it. It could be summarized in defining a common and expressive language that can be used even on remote teams.

Ineffective communication

The resolution of this communication problem is not instantaneous and requires a long process of adaptation and evolution. However, I have decided to focus on this as it is now more important to achieve effective communication. We are working 100% remote because of the exceptional situation we are living and the communication channels have varied. We need that effectiveness.

Our team consists of members with different skills and knowledge: business experts, analysts, developers and testers.
Each group uses a different language causing ineffective communications. Using different languages causes constant misunderstandings. There is no good communication between these groups.

A special group is the developer group. They use their technical jargon to express themselves using code class names in their conversations. This also happened to me when I only developed code. With such conversations it is not possible to reason and deepen in order to solve the problems. The other people who are not directly involved in the concrete development that is being talked about are totally lost and can contribute nothing. If during your team meetings a technical language prevails then those who are not developers cannot participate or understand anything. The developers who produced this code are disconnected from the rest of the team. It’s impossible to have a conversation by detaching from the code.

The most valuable asset we produce is the product code. If you’re inspecting the code and you don’t find words that even remotely resemble words that describe the domain and your model, then you have a very serious problem. You will not be able to understand the semantics of the code with respect to the real problem it solves. It reminded me of when we programmed in assembler or machine code, without being able to hold on to any semantics. Traceability between domain, model and code has been lost.

I do not intend to leave my task as an interpreter and translator, but try to do so less frequently. I intend to have more cross-discussions between team members with different profiles because this will enrich the entire team and all the assets we produce.

Common and expressive language

We need to establish a common language that is used by the whole team to communicate effectively, accurately, avoiding intermediate translations and on which to base a deep conversation based on logical reasoning.

This common language should serve to express the model we have of the domain of our business. This is the approach proposed by Domain Driven Design. The model contains the concepts and relations between them that are abstractions of the domain. Language reserves words to refer without doubt to the concepts and relationships of the domain model. Whenever we want to refer to a concept or relationship we will use the same word.

However, there is no direction happening from language to domain. Through language we express the model, we reason about it and this makes us discover new concepts, relations and restrictions. This in turn causes us to know more about the domain, extracting business rules that remained hidden from our eyes. A double direction happens.

The members of the team define this common language, since by involving them it will be easier for them to use it later. We don’t all have the same language-defining skills. It takes the ability to conceptualize what happens in the domain, extracting concepts and delimiting their semantic borders. Analyzing the relations between concepts. If the domain is abstract this task will be complex because you will not have a physical reference to what these concepts and relations model.

I must admit I had trouble understanding the example of the eskimo tribes. These tribes have a family of words to characterize snow, while desert tribes do not have this abundant expressiveness to speak about this element. Eskimos live in the snow everyday and need to communicate with this expressiveness to survive.

The expressiveness of our language is related to the complexity of our domain and the problems we solve about this domain. Words will show a precision equivalent to these concepts and relationships. The use of each word will be appropriate depending on the context of the conversation at each moment.

Families of words will be formed that represent concepts of the model that are related to each other. In the context of this article we will refer to root words as those words that represent general concepts. Other words representing more specific concepts will be derived from these words.

Evolution of the language

Our everyday language evolves according to the use we make of it. New words are admitted to refer to new things or behaviors. Words that are no longer used are withdrawn. As we know better the domain of our product we expand and refine our model and the language to express it.

New words will emerge to narrow down a concept more precisely. By including these new words in the language, we can discuss about parts of the domain that we couldn’t before. Or they will change the meaning of some of the words to make room to the new ones. The semantic border that delimits each word will be shaped and fitted with the edges of the other words as if they were a puzzle.

There are times when parts of the domain are not covered by the model and therefore the language does not reserve words for them either. When you’re reasoning about these parts, the conversation isn’t natural. You can’t express yourself with the words you have defined, but you also don’t know how to include new words that express this. Then, the product evolves including new features and these uncovered domain parts need to be modeled. The language incorporates new words and now a natural expression is given. Language evolves as domain and product evolve.

As language evolves, it changes your understanding of the domain. Domain is not really something you can perceive entirely from the beginning. It is discovered thanks to the logical process that can be given about the language you have defined.

Use of the language

Once we have defined our common language that allows us abundant expressiveness we should focus on having the whole team use it.

If you keep an active listening attitude during conversations you will have noticed that if you don’t use the language well it is not possible to compare points of view or to go further in solving a problem. It will not be possible to reason deeply in the conversation. Therefore, who speak and who listen should focus on using language properly. When two people use language well in their discussions there is a meeting point between their mental models that have been formed from the words they use.

I have found that there are people who, although this common language is established in the team, do not use it properly. There are some people who do not use the words of the language correctly. In a conversation they use a word but are modifying the semantics of the word according to what they need at that time to present their argument. This happens to them because they have not assimilated the semantic borders defined by each word. There are other people who directly don’t even use the words of language and still use their own words. There are other people who remain anchored using an ancient language, using words that no longer exist or whose meaning has changed. They are people who find it difficult to adapt to the evolution of our language.

We must make it easier for these people to use our language well. The first thing to analyze is reason behind. Perhaps the fault lies in their use of language. Or they may not have the domain model assimilated. Or it could be both. The worst situation is that they don’t have the model assimilated. If you understand the model well then there will be no choice but to make an effort to translate your conversations until their expression improves. You will need to constantly refer to the model to see what concepts the words they use are pointing to. If you don’t understand the model well, the situation gets complicated. In their mind the domain is represented in another way and they are closed to not admitting another different model. For these cases I have not found a solution yet …

Naturally there will be people on the team with the natural gift of understanding and translation. Instinctively these people who cannot communicate well will rely on them to communicate with the rest of the team. You should keep this in mind when you create working groups to always have a translator in a group with people with difficulties using the language.

When a new person joins the team, everyone else will have to work together so this person can understand and use our language. If the person knows our domain it will cost him less to use the language and may even bring knowledge to evolve it.

Each group will use language words to a greater or lesser extent. Domain experts will use more words that represent generic concepts of the model and the rules and restrictions of the domain. They will use the root words of our language. Analysts, developers, and testers will use more words that represent specific concepts, restrictions, exceptions, and limitations of the model. These words were derived in our language from the root words, so understanding will be given between these groups. If it is the case that an expert discusses with an analyst, he will do a task of abstraction between the specific words that the analyst uses towards the root words that he understands best. And conversely, the analyst will do a task of concreteness from the root words to the specific words that he understands best.

When the whole team uses this common language, we get a cohesive team that thinks about the same model. You get a concrete flow in conversations. This flow gives us efficiency and depth of understanding.

The customer and users realize that your team knows about their business when they are in conversation with them and understands the language they uses, as this language is describing their domain. The image of the team is reinforced. The customer can not only talk to business experts and analysts but also to the rest of the team.

We will always use this common language. We will use it in spoken conversations, written communications, writing technical product documentation such as functional analysis, detailed designs, test plans, user manuals, etc. If we do this always, we will have as reference the model of the domain and the erroneous interpretations will be given less.

Representing the language graphically will make it easier to use. We can use a graph for that. The nodes of the graph represent the concepts and the edges the relationships. The names of nodes and edges are the words of language. We can also create a glossary of terms to explain each word, making explicit its semantic edge.

Conclusions

Defining a common and expressive language and getting the team to use it substantially improves communication. It makes the team cohesive and allows discussions between people with a notorious flow.
From this language people build a common mental model on which to reason.

The expressiveness that the language allows eases the incremental discovery of the domain.

We will make easier the use of language for people on the team who have difficulty expressing themselves.