Conway's Law v. Software Architecture

I’ve written about Conway’s Law before (Return to Conway’s Law (2006) and a Focus Group I ran at EuroPLoP “What do we think of Conway’s Law Now?”)

but I make no apologies for revisiting it again because I still think it hold true.

There are times when I wonder if there is any point to the discipline called “Software Architecture.” Sure design can make a difference in the small but when it comes to the big then, for my money, Conway’s Law is a far more powerful force than the plans, designs and mandates of an enterprise architect.

Conway’s Law predates Agile and Waterfall but it applies to both:

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” Conway, 1968

The original paper “How do committees invent?” is available from Conway’s own website. The original publication was in Datamation, April 1968.

While Conway’s Law can be seen at the macro level, the company level, it is also observed in in the small, at the micro level. The law if often restated in the small as:

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

Or

“If you have three developers writing a UI you will get three ways of doing everything (mouse click, menu item, short-cut key)”

For example, if a development team is set up with a SQL database specialist, a JavaScript/CSS developer and a C# developer you they will produce a system with three tiers: a database with stored procedures, a business middle tier and a UI tier. This design will be applied whether it is the best or not. Indeed, the system might not even need a relational database or a graphical interface – a flat file might be quite adequate for data storage and a command line interface perfectly acceptable.

It is a little like a children’s cartoon where the superheroes need to rescue somebody: Superman says “I can use my super strength to lift the ice boulders out of the way”, while Fireman says “I can use my fire breath to melt the ice” and Drillerman says “I use my drill hands to make a rescue tunnel”. Once added to the picture each specialist finds a way to utilise his or her special powers. For a software team this can lead to poor architecture, over complicated designs and competing modules.

In setting up a team architectural decisions are being made even if no architecture diagrams are being drawn. Just deciding to staff the team with four developers rather than three will influence the architecture because work now needs to be found for the fourth team member.

These decisions are made at the time when the least information is known – right at the beginning. They may made by planners – project managers – who have little knowledge of the technologies or by people who will not actually be involved in the development effort, e.g. enterprise architects.

To avoid this my advice is to start a team as small as possible. Try to avoid making architectural decisions in staffing the team by understaffing it. Keeping the team hungry will reduce the possibility of building more than is needed or over architecting it.

There are those who would quickly point out the risk of under architecting a system, not looking to the future and not building a system that can change and grow. But the risks of over architecting are if anything worse. Too much architecture can equally prevent a system changing and growing, and too much architecture leads to more time consuming and expensive code to cut. Then there is the risk of not shipping at all, too long spent producing the “right” design may result in a system too late to be viable.

Second staff the team with people who are more generalist than specialist, people who have more than one skill. Yes have a Java developer on the team but have one who knows a bit of SQL and isn’t scared of a little UI work. In time you might need to add database and UI specialists but delay this until it is clear they are needed.

These suggestions echo Conway’s own conclusion at the end of his paper:

“Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity.”

It is worth remembering that Conway was writing over 20 years before Womack and Jones coined the term Lean to describe Toyota.

Reverse Conway’s Law & Homomorphic force

Since Conway wrote this a lot more systems have been developed. Many of these systems are now referred to as “Legacy Systems.” In some cases these systems force certain structure on the team who maintain the systems and even on the wider company.

For example, take the 3-tier database, business, GUI system from above. Years go by, the original developers leave the company and new staff are brought in. Perhaps some of these have been and gone in the years. The net effect is a system so complex in all three tiers that each requires a specialist. The database is so rich in stored procedures, triggers and constraints that only a SQL expert can understand it. The GUI is crammed full of JavaScript, CSS and not HTML 5 that only someone dedicated to interfaces can keep it all working. And the middle tier isn’t any different either.

Given this situation the company has no option but to staff the team with three experts. Conway’s Law is now working in reverse: the system is imposing structure on the organization.

Again this happens not just at the micro-level but at the macro-level. Entire companies are constrained by the systems they have. Economists might call this path-dependency: you are where you are because of how you got here not because of any current, rational, forces.

Underlying both Conway’s Law and Reverse Conway’s Law is the Homomorphism, or as I prefer to think of it: The Homorphic Force.

This force acts to preserve the structure of system even as the system itself moves from one technology to another, from one platform to another.

Both forms of Conway’s Law and the Homomorphic Force pose a dilemma for any organization. Should they work with the force or try to break it?

I can’t answer this question generically, there is too much context to consider. However I tend towards saying: Work with Conway’s Law, not against it – like woodworking, work with the grain not across it. Be aware of Conway’s Law and Learn to play it to your advantage.

Conway’s Law does contain a get out clause: the system that will be created will be a copy of an existing system, if you can create a new system, a system not pre-loaded with assumptions and well-trodden communication paths then maybe you can create something new and of a better design.

Thus I sometimes view myself as an architect. Now I don’t think I’d accept membership of the Architects-Club even if it was offered, and probably my software design skills are not up to the job but it doesn’t stop me dreaming.

But I architect by (trying) to bring about a good organizational architecture which will in turn bring about a better system architecture via Conway’s Law.