The biggest problem in software is not related to develop but to people coordination:

• Stakeholders talk a different language than developers.
• Developers have different opinions on how code should be written.
• UX designers don’t usually discuss with frontend devs to see how easy is to develop one or another approach.

Communication is a way to solve coordination problems but communicate people inside an organization is a very time-consuming task, perhaps the more time-consuming task you can imagine. But without communication is impossible to achieve the goal, the cost of implementing a different thing than the one our clients want is very high.

So it is like an impossible problem, we need communication but the communication has a big cost. What to do?

Inside the organization

Microservices are just a simple way to split our big codebase in several ones. Those deployable codebases (services) must minimize dependencies between them. Following the Inverse Conway Maneuver this will produce that the team in charge of microservice A will be very independent of the team in charge of microservice B.

Now both teams are autonomous and independent then we have reduced the need of coordination between them, also we have reduced the cognitive load.

If your teams are not in charge of one or some microservices in reality you have a bigger problem than having a monolith (few benefits and poorer performance). You will notice some advantages like fewer conflicts when changing code because it is going to be more difficult to have two devs of different teams working in the same codebase. But coordination problems will be still there, you will start feeling that your speed developing decreases.

The same happens if your microservices are not independent. This will be reflected in teams coordination, two teams in charge of two very coupled microservices will need ways to coordinate their work (more communication between teams then higher costs).

Now imagine that you slice vertically your product and you give the responsibility of each vertical slice to one team. In this scenario we have reduced the coordination between those teams maintaining the quality of our product, because those teams don’t need to talk between them. We can introduce more teams in charge of vertical slices of our product. Slicing more and more vertically our product will force us evolving our architecture to simplify our teams work.

Inside the teams

Probably you have faced the problem of not having tasks to take because all of them depend on others that have not been finished. In this situation the only thing we can do is talking with our team to define a plan to avoid being blocked (coordinate between us with a meeting).

There are several ways to avoid this coordination in form of meetings, at least from a development point of view:

• Trunk Based Development is a way to simplify that problem, because you don’t need to wait until the whole task is finished to share your code.
• Having different independent streams of works allow also to have developers always working in a task.
• Transferring knowledge requires a lot of communication, try pair programming to do it more effectively.
• If you do pairing rotate pairs to avoid silos. If not, create mechanism to avoid the same people working always in the same stories.
• Code reviews requires a lot of communication, make them smaller or even better start pairing.

#software-development #coordination #meetings #technology-radar #microservices