« Consistency vs. Innovation | Main | Let's Kill Productivity! »

Sunday, November 28, 2010



I like to think that the law applies both ways. This is particularly true in the case of open source projects.

Each project starts out from more or less a mess and then works out source structure to fit some suitable governance model. Just consider the development of Linux and the way it went (Linus -> Multiple devs -> Lieutenants (Linus doesn't scale)).

I also consider that the law applies on individual level as well. Pretty much any code you write reflects the way you think.

An organization may constrain this. For instance you might code more defensively in organizational setting than at home when you are doing just some happy hacking. :)

I think the main gist of the law is that in order to improve your codebase, you really need to work on your organization and vice versa. Just throwing some hip new techniques to the coders and expecting that to do the trick won't do the trick. It's more complicated than that. :)

Sri Shivananda

Thanks for the article.

It is amazing to see how few of the organizational design conversations actually reference and utilize conway's law as a design principle.

I do believe a good, empowered enterprise architecture practice can actually dampen the affect of conway's law. However, it is a force that even in spite of best collaboration across teams, manifests in ugly ways sometimes causing organizational sclerosis.

I think, decomposing a large system to components is also a discipline that requires a good modeling discipline and careful thought. Design the components too small and you will get complexity in architecture coming from a dense network of component dependencies in spite of organizational alignment to components. Design it too large and organizations supporting those components will have localized inefficiencies due to serialization of delivery and contention.

Lastly, Conway's law affects are very clear in geographically diverse engineering organizations. Designing off-shored engineering organizations should be one of the first places to apply this principle.

The comments to this entry are closed.