Conway's Law states that "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations". Melvin Conway coined this aphorism in his paper "How Do Committees Invent?" in 1968.[1]
The typical formulation of this principle from Eric S. Raymond is "if you have four groups working on a compiler, you'll get a 4-pass compiler". A more irreverent version from Tom Cheatham states that "if a group of N people implement a compiler, you'll get an N-1 pass compiler: someone has to act as manager."
Witticisms aside, there are sound reasons why organizations create systems "in their own image". It is easier to collaborate with people that work side-by-side with you than people separated by bureaucratic or geographical barriers. If you want to create something large that requires technical know-how and cooperation, you are quite likely to create a module working with your immediate team members than strangers with whom all you share is a corporate logo. You are likely to do this even if the module you create ends up causing unnecessary redundancy, increased coupling or even incompatibility with modules produced by remote teams.
It's perhaps even more understandable when such problems arise in organizations which create software. Software has none of the physical characteristics -- mass, length, width, density, temperature, etc. -- that many other products of human engineering have. In a way, it's the purest expression of creative and scientific thought; prone to the fallacies and shortcomings of all human thoughts. Thus organizations are compelled to create software whose structure mimics the "communication-pools" -- the teams, departments, divisions, floors, buildings, hierarchies, cities, countries and societies -- that comprise the organizations themselves.
Knowing this, it's highly advisable for organizations to align the communication-pools with a view to optimizing the goals and objectives of the software being created. However, in my consulting work, I've all too often observed organizations that have chosen to structure themselves in a way that is at odds with their stated goals and objectives. In extreme cases, the structure of such an organization actively subverts its raison d'être. Such self-defeating structures exhibit what I call Organizational Dysmorphia.
A recurring example is when the development and quality-assurance teams are isolated from each other and evaluated on mutually conflicting criteria. The development team is measured on the amount of functionality (feature-points, story-points, etc.) that they deliver to the QA team. The latter, in turn, are measured on the number of defects they can find in the software they receive from the development team. This arrangement actively dissolves any collective focus on quality and instead promotes a highly localized -- almost selfish -- way of thinking about one's job.
I observed another, more subtle example recently at a company. Some developers were responsible for creating interfaces. Others were responsible for implementing those interfaces. Apart from not promoting collective code ownership, this doesn't sound so bad at first. However, when you reprimand and reward (financially and otherwise) the different individuals based on exactly how the resulting software got broken and was then fixed, things quickly spiral down into a finger-pointing, responsibility-avoidance culture rather than one that values collective effort towards relentless quality improvement. This is what I found at that company.
Yet another example -- which only appears comical in hindsight but was quite frustrating when I found myself in it -- was when a US-based company asked us to do a project Quickstart [2] to launch their online product in a non-English speaking country. My colleagues and I found to our surprise that not one of the 20-plus participants in the Quickstart had any expertise in the language and culture of this new country. Somehow they expected to simply export an internationalized version of their product to this new country -- without utilizing any communication channels with their colleagues in that country. (There were such colleagues; they simply weren't invited to the Quickstart to keep the costs down and the logistics simpler.)
Organizational Dysmorphia is consistent with and is a specialization of Conway's Law. Conway's Law is neutral: organizations are constrained to produce systems that mirror the communication structure of these organizations. Organizational Dysmorphia is the subcategory that deals with severely abnormal and dysfunctional instances of Conway's Law.
So what do you do when you find your organization exhibiting symptoms of Organizational Dysmorphia? There are concrete steps you can take to both avoid and cure this malady. The next article in this short series will go through some cures.
[1] How Do Committees Invent?
[2] MartinFowler Bliki: Quickstart
