neverstew

This article attempts to distill some thoughts about Conway's Law and the resultant pros/cons at Residently. Only recently have I started to think a lot more about Conway's Law and how it might apply to the structures that I find myself a part of. This has mainly come about due to observations of pain points in the Residently structure that have arisen as the team has grown.

Conway's Law

Not everyone ascribes to it but I have found myself agreeing with the notion behind it. More importantly, I think, is to view it not as a constraint but as a description of the way in which we naturally, efficiently, understand and communicate about systems.

Software is inherently, I believe, a people problem. I don't work at the scale where micro-optimisations are the name of the game and probably never will. For me, software is about solving problems. In this sense the largest constraints are the understanding of problems and the process of ideation and testing the solutions you design. The name of the game here is to be able to build your system as easily as possible in any direction that might be required. Anything that gets in the way of iterating on the idea is preventing the team from progressing at its most fundamental level.

Enabling progress in small teams

With that frame of mind, Conway's Law would suggest that the best way to enable a team to iterate on ideas is to design our systems in line with our team structure.

This firmly suggests to me that microservices, multiple repositories and other forms of distributed modules within a system are a terrible idea for small teams. This conslusion resonates with what I see day-to-day and provides a nice explanation/guiding hand for future projects that I might undertake.