This post is a part of How To Ship Maintainable Product series

Communication is the most basic and core aspect of every group. That applies also to software development teams, departments and organizations.

Exchanging information helps us to understand the surrounding area in a better way. We are more synchronized and can take better decisions.

On a high level, it is very important to create a structured and simple way of communication.

Why communication is important and necessary

There are 2 levels of communication: 1) internal and 2) external.

Internal communication

This type of communication can be described as a tribe language or slang. Commonly used words may have a totally different meaning in internal communication. Let us consider e.g.: bug word. Generally, it is an insect, but in software development language it means a program defect.

The key is to have a defined vocabulary understood by the whole team in the same manner.

External communication

External communication should be aligned with the organization way of sharing information. This can include TL;DR;, abstract, summary, call-to-action and other items mandatory in such message. There should be a communication protocol defined. It can be very official, but that is not required.

Remember that communication details should be adjusted to the message receiver. We probably don’t want the board-of-directors listen to some tools we made to improve log parsing.

Communication tools

A number of tools were invented to improve communication. Email, CRM, chats, SMS etc…

My advice here is to use what suit best our needs. The only requirement it is that the channels should not overlap or duplicate, because it such case the communication gets blurry.

Domain Driven Design

In software development, we have many issues in communication. That’s why technical debt grows and software is still hardly maintainable.

That’s why Eric Evans introduced the term Domain Driven Design and Ubiquitous Language concept. Wikipedia describes it as A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Danger

There are some things we should think about when creating or improving our communication:

• Don’t bend or break the rules - otherwise everybody will
• Compose right message for the right audience
• Respect other people response time - this is an asynchronous communication

Summary

Here are some takeaways:

• Be clean and precise
• Use agreed language
• Use agreed protocol
• Use agreed communication channel