Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Conway's Law v. Software Architecture

03.14.2013
| 8266 views |
  • submit to reddit

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 utilize 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.

Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sun, 2013/03/17 - 3:17am

We're as likely to use an architecture we're familiar with as to use one with the technologies that we have skilled developers for.  There is probably as much risk in using new but more appropriate technologies and having to learn the skills as you go.

In the interest of lifetime maintenance, the most important thing may be to keep it as simple as possible, preferring fewer technologies if possible.

Claudio Lyra replied on Thu, 2013/03/21 - 5:16am

Hi Allan, 

Very interesting article, good material for thought.

The first idea that crossed my mind was to re-phrase Conway´s law as "the signature of the creator is present in the creation". But then, reflecting on it, I realized this version was not so good. Conway´s argument is not that some "inner qualities" of designers can be perceived in the artchitectural blueprint. Conway used the word "communication".

Communication implies multitude of people. Besides, does he mean vertical or horizontal communication? Or both? hmmmm

My second tentative of summarizing the core idea of the text in my own words was: "architecture evolution mimics team structure". Seems more reasonable and it is in tune with your excellent super-heroes analogy.

However, we know how often design is affected by physical constraints, like new technologies imposed from top to bottom insise organizations, or like not uncommon resume-based software decisions. Therefore I felt compelled to modify my statement to "architecture is molded by resource commitments". 

If there are no upfront resource commitments, either human or technological then design is free to evolve according to the capacity and will of its designers. If not, the result will reflect the external structure to which the project is locked in.

But I still feel this is not all. Humans are humans, that is, we can´t simply ignore that subjective and immaterial factors do play a role. Communication is the inter-relationship of people. People have likes and dislikes; people know some things in detail but are totally ignorant of others; people proceed according to unspoken agendas; people interact through politics.

So, in addition to "architecture is molded by our resource commitments", I have considered the complementary phrase "design complexity is the signature of its creators"; at the end, back to my own original attempt, but at least now I feel that the two heads of the monster have been exposed, the visible and the invisible one.

Note: complexity would be measured by things like the number of software layers, the existence of disparate technologies, the variety of ares of expertise, etc.

Maybe I have deviated from the ideas of the original paper, but the above seems to make sense to me. Not it is time to download and read the original. Once again, thanks for triggering these very interesting reflections.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.