Return to Conway’s Law

Are software architectures copies of the organizations that create them?

Often this is true but is it always true? And more importantly is it a good thing?

In 1968 Melvin Conway wrote a paper that discussed this topic. It has since been passed down as developer folk law that.

“If you have 4 developers writing a compiler you will get a 4 pass compiler”

Or,

“If you have 4 developers writing a GUI based system you will have 3 ways of doing anything (mouse, menu and shortcut key) - only 3 because someone has to manage the others.”

There is even a pattern by Coplien and Harrison (Organizational Patterns of Agile Software Development) of this name that describes the situation in more detail.

Trouble is, things are just more complicated than that.

What if your company is bought? What is the relationship between architecture and organization then? Or, if your development is outsourced? What if you are geographically separate? What if you adopt Extreme Programming?

And, have things changed since 1968?

In an attempt to understand the “law” and answer some of these questions Lise Hvatum and myself facilitated a focus group discussion at EuroPLoP 2005. The resulting write up from both of us is now online at on my website.

So what do I think about Conway’s Law?

Well, I don’t think Conway’s Law is a law, in that much I agree with Kevlin Henney, it really describes a force. And the name of the force is Homomorphism.

I believe Homomorphism is a strong force, I believe it is always present, I believe it was stronger in the 1960’s but it is still strong and most importantly it is self-reinforcing. I also think its the default architecture for most organizations.

I agree with Neil Harrison, in the ABC case study the organization changed from one structure to another and the architecture followed, they stayed within "Conways Law."

The big question for me is:

• Which comes first: Organizational structure or Architecture?

Conway was right when he said that the design that occurs first is seldom the best. Question is: how do you create a better one when the existing one is self-reinforcing?

More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology - they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.

All too often technology companies respect those with technical skills and ignore the need for management skills, they reward those who are technical more than those with good management ability.

When I think of the really good technical people I know, myself included, sooner or later they all come to the point where they realise that to solve technical problems requires them to work outside of the technical domain.