Melvin Conway has a law that I’ve heard thrown about throughout my career building applications and backend systems. Verbatim it states:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Or, put simpler - your system/product/service/software reflects the organization of teams interacting with and building it. I’ve seen this play out over and over in organizations I’m intimately familiar with and ones I’ve been a curious outsider peering into.
The law has been reworded and remixed once embraced by the software community. There’s even a fun corollary conjectured that long-running systems not only represents the current team’s organizational structure, but also the organizational structures of prior development teams.
I’d like to submit my own corollary; one that, while I’m not confident on its originality, I’ve not seen stated elsewhere. Like the base law, I can say confidently I’ve seen its effects cause issues.
If a system is designed in a manner that is the antithesis to the structure of its supporting teams, the system will fail.
Or, simplified - don’t introduce unnecessary friction just because you tried to be clever in your design. As a software architect you must pay attention to your team structure and processes or what you build will be the bane of too many coworkers' existence.