Imagine you’ve joined a new company as a Software Architect in a team of four engineers. Your company is a large corporation with divisions spread across the globe. Since you and your teammates are in the same room, communication is easy. All it takes is to turn your head left or right to start a conversation on a given topic or problem. The rest of your colleagues can join in at any time, providing valuable input or time-saving observations. You can set up a meeting quickly, gather in the social room with a nice cup of coffee, and exchange knowledge informally and in a friendly manner. In such a setup, the architectural outcome will likely be a monolithic application, preferably modularized. And so, it was in this case.
New Team in a Different Location
After a few months and several business meetings, the decision was made to enrich the system with some heavyweight features. It was clear from the beginning that your team alone wouldn’t be able to handle so many functionalities while maintaining the same high quality. Fortunately, your organization is large enough to create an additional development team on short notice, so there’s no need for a lengthy recruitment process or employee onboarding. However, there’s one small inconvenience, your reinforcements are located in a different city.
The most efficient way to communicate with them is through group video calls with screen sharing, and that’s what you tried. But, soon, you realized the other team had a different understanding of the architecture behind the monolith you’d created. They started working the way they thought was right, which led to a series of meetings to clarify what had been misunderstood.
After a few difficult weeks, it became clear that this approach wasn’t successful. Now that there were another four people in the team, the number of possible communication links had increased dramatically. The complex network of peers made communication harder and more cumbersome, especially with the added distance. In this situation, you decided to split the work. The “Other City” team would develop their set of features as microservices, so they wouldn’t have to rely on the existing code and architecture.
Another Team in a Different Timezone
Congratulations, you had found a solution. After the remote team became more independent, they started delivering new functionality more quickly and sticking to the plan. When the news came that stakeholders wanted to add even more features and there was another team ready to join the project, you already knew that microservices were the way to go.
The biggest challenge with different timezones is that when you’re sleeping, the other team is in the middle of their work, and when they rest, you’re on your lunch break. Video meetings can’t be a constant solution; they should only be used for critical situations. Otherwise, they lead to sleepless nights and disrupt people’s natural rhythms, which is unhealthy, even in the short term. With teams spread out across timezones, this resulted in even more independent microservices developed by each team.
Conway’s Law
The solution you arrived at is an example of what Melvin Conway observed in 1968:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Isn’t that exactly what happened in your case? You had to outsource logic and processes to another, independent team. They were allowed to use the technologies they knew best, so all tightly coupled contexts became independent, separately deployed units. As you can see, Conway’s observation holds true -it’s a law, one that likely applies every time project participants aren’t in close proximity, which directly affects communication.
Chris Ford once said to Martin Fowler:
Conway understood that software coupling is enabled and encouraged by human communication.
This quote means that the more easily you can talk to the author of some code, the better your understanding of their work. A brief discussion over a pull request is often all you can rely on, especially when the other team is far away. Fowler explains that Conway’s Law should inform decision-making regarding team organization, though it doesn’t apply to small teams. He suggests that you shouldn’t resist or ignore this law, but rather learn from it and consider it when planning system architecture.
The Attitude
In Martin Fowler’s experience, every project he’s participated in has proven Conway’s Law to be correct. This observation, made decades ago, generally elicits three responses.
1. You Accept It
This is the best option. Sure, your project might be the exception that proves the rule, but that’s a rare case. This is the recommended approach when dealing with a fundamental aspect that has been proven to work. You should always try the proven, well-established methods first. If they fail, then you can look for domain-specific, custom solutions.
2. You Don’t Care
This is the second option. You might disagree with Conway’s Law, have a different idea for dividing labor, or simply believe that things won’t go the way Conway predicted. That’s up to you, but you are encouraged to learn from well-tested, generally accepted solutions to existing or expected problems.
3. You Let the Tail Wag the Dog
Fowler also points out the term Inverse Conway Maneuver, coined by Jonny LeRoy and Matt Simons. With this approach, you change the communication patterns between teams, which will be reflected in architectural changes. However, this comes with significant consequences. It’s unlikely that large, legacy systems can undergo such a transformation without causing new problems. So, it’s important to use this technique wisely.