// thinkbeforecoding

Generalized Conway's law

2013-12-17T09:09:51 / jeremie chassaing
p>Disclaimer: This article is not just about Conway's lay which I'd call Classical Conway's law, it's already on Wikipedia. You'll find its Generalized form at the en of the post..

BuildStuff 2013 has been really inspiring. Talking with all those people from different CS culture always raise the level of the conversation.

 

Several times came Conway's law into the discussion, as Pieter Hintjens noticed in his blog post yesterday.

 Classical Conway's law

Conway's law is quite simple. It states that:

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

 

À partir de l’adresse < http://en.wikipedia.org/wiki/Conway%27s_Law>

 

It's often seen as a joke to mock companies organization, like this famous drawing:

 

 

But it is more than that.

First, it can be a force to drive a change in the system.

 

When two parts are too strongly tied and mangled together, it's a good idea to move teams apart. Communication friction will increase, and eventually, teams will find way to decouple parts so that friction can be reduced.

 

Pieter's example of LSHS vs LSNS is totally an example of this.

 

Second, it is both ways.

A messy system structure reflects a messy team organization.

But we can go far beyond.

 

Generalized Conway's law

System should match the structure of any external concern it interacts with

 

Of course, the Conway's law is included here. There's a match between people building the system and it's structure.

 

But we can here also include design methods like Domain Driven Design which address a different concern the same way:

Align the system structure with the structure of the Domain you're working in/for

 

Using Domain Events and Event Sourcing is a way to make explicit something that is usually implicit in most systems: Time

 

CQRS will reflect the fact that outside the system, getting information and acting on it are two totally different things.

 

Architecture in general is also included: find the match between your system and non functional requirements.

  • Deployment
  • Security
  • Performance
  • Maintainability

At a lower level, it is also known that code clarity reflects the level of the developers understanding.

 

All those external forces will shape the system, and any mismatch in structure will create friction.

And any smell in the system is a sign that something is not understood or working well outside of the system.

 

Generalized Conway's law gives a higher frame of thought to find what's ok and what's wrong in all the dimensions of building systems in interaction with their environment.