Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. –Melvin Conway
Are they? Sure, there is ample evidence to suggest that the architectural structure of software closely parallels the organizational structure of its creators, but this “mirroring” is a correlation, not a causation.
Consider ye olde three-tier web application architecture: there’s ye olde persistence tier, ye olde business logic (typically server) tier, and ye olde presentation tier (much of which dwells on the client side these days). Has the ubiquity of this architecture sprung forth from the inherent propensity of engineers to divide into UI, database, and server specialties… just because? Are the UI people just too hipstery to be tolerated by the backend folk? Do DBAs smell funny?
Or it is because the skills to be mastered by owners of these tiers are so numerous and discrete, that specializations in these tiers becomes practical and natural? On the database side, there is the complexity of organizing data, indexing data, replicating data, retrieving data all in a platform-specific way. On the UI side, there’s the ever-growing number of user form factors and a cannonade of web frameworks. If there weren’t enough hours in the day for one person to master all three tiers, wouldn’t specialization by tier be inevitable? And if the difference of skillsets required for specific tiers was greater than the difference of skillsets required for specific projects, wouldn’t teams naturally specialize by tier and not by project? I submit that the inherent complexity of software components and tiers forces contributors to specialize in dealing with those components and tiers. And it is this inevitable specialization that causes teams to organize in a manner that mirrors the organization of their respective components and tiers.
Specialization is nothing new. David Ricardo developed the theory of specialization by comparative advantage in 1817. It states, at its simplest, that if John is better at growing apples than he is at growing oranges, and Jane is better at growing oranges than she is at growing apples, then John should grow apples, Jane should grow oranges, and they should leverage each other’s output through trade. When they do, they operate at their peak combined economic efficiency.
All this begs an ominous thought: Conway’s Law has been used to rationalize organizing teams around developing microservices. But given the possibility that it is a false causation, should organizing teams around Conway’s Law be considered harmful? Dum dum dummmmm! (To be continued…)