“If you have four groups working on a compiler, you’ll get a four-pass compiler.”
This quote, coined by Eric S. Raymond in The New Hacker’s Dictionary, summarizes in a simple way one of the most well-known ideas in software engineering: Conway’s Law.
The idea is simple: the way people work, communicate, and divide responsibilities can influence the way software is built.
This can be observed in different situations. Imagine a company organized into departments:
- Sales
- Finance
- Logistics
- Customer Support
Since the company follows this structure, its system may also be divided into modules or services related to these areas. In this case, the boundaries of the software may end up reflecting the boundaries of the organization itself.
This relationship can have both positive and negative effects on the architecture. Teams with clear responsibilities, good communication, and simple processes can contribute to a more cohesive architecture.
On the other hand, poorly defined responsibilities, poor communication, and complex processes can end up creating unnecessary coupling, dependencies, and complexity in the software.
That’s why, when analyzing the architecture of a system, it’s worth looking beyond the code:
- How are the teams organized?
- How do they communicate?
- Who is responsible for each part?
- Where are the dependencies?