Conway’s Law
Recently I reread TMMM to refresh my memory. Although the book is showing its age, I rediscovered a couple gems. One gem that author Fred Brooks mentions is Conway’s Law. In years past this maxim was not well known, but it has gained favor over time.
Conway’s Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
In Software Engineering terms this might be stated as: Development organizations that are centralized tend to produce single code bases and/or monoliths, whereas distributed or decentralized teams tend to produce modularized/distributed systems.
Conway’s Law In Practice
Conway’s Law matches my experience. At my smallest startups the sole team naturally focussed on a single code base or product. If we hired folks outside the central office we did so carefully, and flew them into Silicon Valley for extended consultation. We avoided divvying up the code before it was necessary to do so. When the future of the company is tentative at best, adding additional overhead means adding more risk.
At the larger, more distributed enterprise organizations I have been a part of (Adobe, AppDirect, and Salesforce) we spent considerable effort determining the best team size/distribution and corresponding ownership of code. Some sort of modular and/or distributed system was necessary in order to allow various teams to efficiently focus on their domains. The clarity of this separation was a key factor in how effectively (or ineffectively) these organizations were able to develop and adapt their products. The large organizations that could not effectively modularize slowed down to the pace typically associated with, well, large organizations…
If a team or organization remains relatively static in terms of people, responsibilities, and locales it can settle into a distribution of people and products that works effectively. The reality tends to be more like some sort of punctuated equilibrium, where static periods are followed by either rapid growth, fusion, or reduction. When these changes occur it necessary to evolve the teams (and code base) to the new norm.
Efficient Teams and Code
Following Conway’s Law, small team sizes naturally align with segmenting/modularizing the code into smaller domains, so that the structure of the organization and the system remain in alignment. Large teams, whether centralized or decentralized, gravitate toward burdensome communication and complex monoliths.
Whatever your scaling circumstances consider the two pizza rule and organize small teams. Keep the core between 3-6 engineers (dev and qe). At this size communication is relatively simple and direct, yet the team is large enough to have ownership and responsibility for specific domains. Smaller teams also facilitate efficient decentralization, as they require less time(zone) consuming interaction between each other.
SAAS/Cloud based organizations have excellent modularization options with microservices/SOA and the growing wealth of tools to support them. Used appropriately, Services are a powerful, flexible option which align well with small, independent teams and code bases. But there are many software realms for which Services are inappropriate: embedded systems, mobile apps, AI algorithms, etc. As mentioned in an earlier post, don’t grab shiny new technologies like microserves because they are currently hot. Pick the appropriate technologies that will enable you to efficiently distribute/modularize your code to match your team structure.
Summary
The summary, like Conway’s law, is simple: Create and maintain an engineering organization comprised of small, efficient teams. Don’t fight that organization structure with a large monolithic code base. Instead find effective ways to break up the code to match your organization.
Further Reading
To dive deeper into Conway’s Law consider these good sources: