Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.This makes sense to me. A product like Eclipse -- with loosely coupled components and a very small kernel -- can only result from a loose "open source" organization with little central control. On the other hand, an organization with a rigid command structure and central planning is most likely predestined to produce software that is unwieldy and difficult to change.
It also suggests how designing the wrong organization can result in gaps in a system design. I know of one client software project that never had a network group although one was desperately needed. The hope must have been that a network layer would emerge out of the shared requirements of many groups, but it didn't happen. Because there was no assigned responsibility for a network layer, each group created a different set of network utilities.
Dr. Conway calls this phenonmenon homomorphism. There is a "structure-preserving relationship" between the organization and the design it produces. This insight is significant in itself, but Dr. Conway also develops some interesting corollaries. One of them is:
... the structure of the system will reflect the disintegration which has occurred in the design organization.In other words, when two groups in the organization do not communicate well, the components they produce will not communicate well either. This suggests a better way to monitor progress in software development. In addition to monitoring the progress of individual components, we should also be asking are groups X and Y communicating well? If they aren't, it might indicate an impending breakdown in the design.
While reading How Do Committees Invent?, I experienced several "Ah-ha" moments. Once again, I am amazed something written in 1968 is still relevant today. Follow the preceding link for the full text of Melvin Conway's article.
The truth about Google. I found my way to Conway's Law by reading Don Norman's essay called The Truth about Google's So-called Simplicity. That is also interesting reading.
2 comments:
I've certainly used Conway's Law to explain bad code due to bad organizational structure but I wouldn't go so far as to say that Eclipse's code structure is the result of the Eclipse organization.
Eclipse's architecture was the result of building a platform rather than a product. It's an "ecosystem" for building plugins that can be built up into products.
The Eclipse core and architecture was developed by a small group of very experienced people at OTI. Most of the committers are still IBM employees. While it's true that the teams are distributed, many of them have worked together for years. They work well together despite the fact that they're distributed.
Hi, Bob.
I agree the Eclipse code structure is not caused by the Eclipse organizational structure, but I think there is a relationship between the two.
Eclipse started at OTI and was donated to the open source community. Although the OTI folks remained involved, several new Eclipse committers joined over time. As it evolved from an IDE to a rich client platform, it was divided into platform, JDT, PDE and many other subprojects. Change and flexibility are constants in the Eclipse "organization" and I think that is reflected in the product itself. Or maybe it is the other way around. Maybe the organization has adapted to produce the best product.
In fact, that is really the point of Melvin Conway's article. He warns against building an organization that is more about politics than the product. He emphasizes organizational flexibility over empire building. I think Eclipse is a great example of those principles.
Post a Comment