Conway's Law

How many of you have heard of Conway's Law? Melvin Conway postulated in 1968 that:

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

I usually paraphrase it into:

Software architectures will reflect the structure of the organization that built them.

Of course stated like that, there is a sense of fatalism. Our organization structure is possibly flawed, sub-optimal so of course we'll wind up with a software architecture that is also flawed and sub-optimal. I prefer to look at the law from the other direction though. Start with the architecture, then derive the organization.

This is something that is contrary to how most companies think though. The idea that you would create your architecture component diagram first, then design your entire technology organization to support the architecture isn't your typical process. In some cases it works out that way through organic growth or even through a logical accident of fate where teams form as components spin off. These fortunate evolutions, when they occur, provide the framework for good architectures, but why leave this as an accident of fate?

Starting a new product? Start with a small senior team and focus on determining your component architecture. From there, you can create your organization to deliver that architecture. The teams will become obvious, formed around components so that high frequency communication occurs within teams and lower frequency communication across teams. Your component interfaces become your team communication boundaries. Of course, this also lends itself well to agile processes which is an additional benefit.

What if you have a legacy architecture? How do you improve your existing architecture? The same way. Figure out how you want your architecture to look and then before doing any engineering work, reorganize to create an organization structure that reflects the desired software architecture. This will potentially be suboptimal in the beginning but it will become a forcing function to drive change. The benefit is that the organization will draw the new architecture out of the code because it's the only way the teams can become more effective.

Approaching organizations in this way provides the opportunity to form teams with a higher sense of ownership as well. So many companies attempt to achieve quality through process, governance, checklists, sign offs, and many other impediments to delivery. The hope is that through all these processes poorly built software will not be released to site. The reality is the best way to achieve high quality software is to give people a sense of ownership in the code they write.

If you align your organization around your architecture and create teams that fully own a component, then the natural result is a better quality product. Quality that becomes inherent and owned by the people creating the software, without heavy processes that impact the efficiency of the team.

Ready to apply Conway's law to your company?

architecture, engineering, programming, software, to_read, toread

Comments

[bebraw]

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.