A while ago, I wrote about people problems and explained why process changes cannot fix them. This is still true, and it’s very important to address people problems directly. However, there is one more thing I’d like to add: it’s possible to somewhat mitigate certain people problems by increasing modularization. Note that this doesn’t mean that the problems are solved. They are just made less painful. If it’s not possible to actually fix the people problem, it can be a good idea to explore such mitigation options.

Using modularization as a mitigation technique is only an option when the people problem lies within a development team or between development teams. Basically, the idea is to further modularize the code, thereby isolating the disagreeing people from each other. In the context of this post, modularization means adding any kind of additional substructure to the code with the goal of decoupling teams from each other. This can be a traditional method like adding a dedicated package or a software module as well as moving the code into a standalone service. As a sidenote, I think that the popularity of microservices is at least in part motivated by the desire to isolate oneself from other development teams. This is why some teams desire to move their code into a microservice even though they have no scalability issues.

But how exactly does modularization mitigate a people problem? It mitigates the issue by increasing empowerment. As soon as we have our own module to do as we please, we need to coordinate less. That means that certain conflicts can be avoided completely because a consensus is no longer needed. For example, let’s imagine that we have a long-running conflict between two development teams because the two teams cannot agree on what static code checks should run in the development pipeline. As soon as we give each of the teams its own module, the conflict just vanishes as each team is empowered to do as it pleases. Another example that I have encountered during my work is that two teams share a module, and one team likes to add a lot of brittle integration tests, which makes it more time-consuming and difficult to merge code changes. As the module is shared by both teams, everyone is affected by this even though only one team likes to invest in these integration tests. Naturally, this causes friction. Splitting up the module into two mitigates the issue, as now only the team that actually owns the tests is affected by them.

The examples given above might seem a bit silly to some readers. In the grand scheme of things, these seem like tiny problems that are hardly worth debating. However, these small things are often debated with great intensity. Hence, it can cause great resentment if no suitable solution is found. Fortunately, these issues can usually be solved by empowering the teams further, which leads to better results in general. That said, it’s possible to split up the code too finely. A good indicator for a too fine-grained split is that we make changes in multiple modules for a single feature. Also, modularizing the code based on conflict avoidance can lead to quite awkward splits, especially when the team setup changes. In general, we should only modularize the code if the resulting split makes sense independent of any personal conflicts. This is especially important if we’re using a very distributed architecture like microservices, as adding an additional service has a much higher cost than just adding an additional module.

Last, I want to stress that these kinds of mitigations are only a second-best solution. We should always prefer solving the people problem instead. It can be tempting to just do the modularization instead because it can be less painful, but this is unlikely to produce good results in the long run.

Conclusion

Most hard problems in software development are people problems. In certain cases, we can try to mitigate a people problem by increasing modularization. While this can be helpful, it’s only a second-best solution.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.