Conway's Law

It works both ways

Conway's Law is an underrated, or at least, underused design observation. In short, it asserts that:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

In other words, the interfaces between components mimic the interfaces between the component teams. This may seem a little trivial at first, but I find it the basis for numerous significant design decisions.

Does your proposed design confound existing organisational structure?

Interfaces between internal teams are often not taken as seriously as they ought to be. It's assumed that people will talk, resolve their problems and everything will work out in the end. Even with the best will in the world, not all developers will be able to reconcile the various demands placed on them. For example, the desire to add features for one colleague whilst maintaining compatibility for another can be harder than it sounds.

Suitable design can alleviate these tensions and allow effective communication and development. Conway's Law should help keep us focused on the fact that design matters at development-time, not at runtime (so much).

Do you want to be constrained by existing organisational structure?

The flip-side of designing in a way that appeals to your communication structure is to organise your teams, or allow them to organise themselves, so that both they and the software meet an emergent structure. I believe it can be extremely productive to move developers into the same team when both sides of an integration task are being undertaken simultaneously. However, this has to be kept in check with suitable review; the emergent software design shouldn't become inconsistent or tightly-coupled as the organisational structure shifts to maximise short-term productivity.

Does your design suggest a fantasy organisational structure?

Many software systems need to be able to support requirements that didn't contribute to their original design. This doesn't necessarily suggest modular frameworks, however. The provision of a modular system is appropriate to organisational structures where release schedules can't be aligned, communication is best undertaken via SLAs and APIs or the extraction of a core set of features can demonstrably add value (ie, to more than one team).

I've seen, and written, numerous systems that will theoretically support all kinds of requirements through the addition of suitable modules. Those systems would have had to have become as popular as, say, the Eclipse IDE in order to reap any rewards from this design decision (they didn't become that popular and weren't required to). While some abstractions serve to contain complexity, others may be introduced to generate needless complexity: will your organisation ever develop your system in a way that will make your design appropriate or is the set of other possibilities more likely?

The link between design and team structure is critical to maintaining a productive development practice. It's particularly important at the level of the system architecture where the organisational structure is far less driven by the needs of your particular project but dependent on your design choices nonetheless.

About the author

Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan developing front-office trading solutions.

While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).

E-mail : kevin.seal at codingthearchitecture.com



Add a comment Send a TrackBack