Collective Code Ownership
When it is always only the responsible team that can introduce changes to a microservice, a number of challenges result as described. Therefore, it is worthwhile to consider alternatives. Agile processes have led to the concept of “collective code ownership.” Here, each developer has not only the right, but even the duty to alter any code—for example when he/she considers the code quality as insufficient in a certain place. Therefore, all developers take care of code quality. Besides, technical decisions are better communicated because more developers understand them due to their reading and changing code. This leads to the critical questioning of decisions so that the overall quality of the system increases.
Collective code ownership can relate to a team and its microservices. Since the teams are relatively free in their organization, such an approach is possible without much coordination.
Advantages of Collective Code Ownership
However, in principle teams can also modify microservices that belong to other teams. This approach is used by some microservice projects to deal with the discussed challenges because it entails a number of advantages:
- • Changes to a microservice of another team can be faster and more easily implemented. When a modification is necessary, the change does not to be introduced by another team. Instead the team requiring the change can implement it by itself. It is not necessary anymore to prioritize the change in regard to other changes to the component.
- • Teams can be put together more flexibly. The developers are familiar with a larger part of the code—at least superficially due to changes that they have introduced in the code. This makes it easier to replace team members or even an entire team— or to enlarge a team. The developers do not have to ramp up from the very basics. A stable team is still the best option—however, often this cannot be achieved.
- • The distribution in microservices is easy to change. Because of the broader knowledge of the developers it is easier to move responsibility for a microservice to a different team. This can be sensible when microservices have a lot of dependencies on each other but are in the responsibility of different teams that then have to closely and laboriously coordinate. If the responsibility for the microservices is changed so that the same team is responsible for both of the closely coupled microservices, coordination is easier than in the case where two teams were working on these microservices. Within one team the team members often sit in the same office. Therefore, they can easily and directly communicate with each other.