The Conway's Law
This is an adage in Software Engineering, and it goes like
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” — M. Conway
It’s been there since ages, even there in the Mythical Man Month by Fred Brooks. It sounds a little funny perhaps but, if we look deeper it is very natural and is a valid sociological observation.
Does the above figure look familiar?
Communication plays the most important role in software development. It sounds obvious but, for techies this has to be constantly in our mind as we tend to drift towards what we like doing. I had a change of thought with the book Domain Driven Design by Eric Evans, and his talks. The essence is that software is always facilitating a certain domain. Immediately, the focus is shifted towards the “domain” i.e. away from architecture, technology, design (all the good stuff). Hmm… well these things exist but they are driven by the domain. What we will get by this is a software that is desired by its users. It is one of the parameter of the product’s success.
Hence, we can conclude that better communication will lead to better software (it also depends on how well it will be implemented but, still its going in the right direction).
Software as a whole may be monolithic or it will be composed of various components - depending on the requirements. However, there will be parts of the software that are developed by different individuals. The way in which these individuals communicate, will affect their design.
Example
Lets say a team ‘C’ is developing a software product, team B is providing a functionality which can be integrated or consumed into the product. If teams are closely located or communicating frequently their designs will harmonious, they will not have to define their own models. On the other hand if the teams are not frequently communicating, they will come up with a more formal interface (similar to their formal communications) and each team will device their internal system which is not visible or of interest to other team apart from the common interface.
Sometimes, this system results into a cleaner design as it is separating the concerns, as the system works and everyone is happy about their components. However, if the goals of the two teams are different the designs may not be compatible. Also, if the design needs to evolve to reuse / reduce redundant code at both ends, if the changes in the system are frequent, requirements change - different teams may not respond in similar ways to them, and the design will be affected by it. For changes / scenarios like these, the teams will need to change the way they communicate.
Conway’s Law is a tool to understand as to why the design has a certain attributes, it is only a natural tendency of the system.
Further reading
More posts