Conway’s Law and Code Ownership

Conway’s Law is one observation we can use as a guide on the initial stages of a Software project, it basically states that development modules organize themselves around the communication structure of an organization. So simply put, if you get three guys in a room that want to quickly roll-out a compiler and not interfere with each other’s work, you will have a three part compiler. Why? because each person does not want to know what the other is doing as long as each has stuck to an agreed interface, everyone is happy.

So, an architectural decision has been made, not by a best practice but by social communication. If the same three developers collaborated on a high-level architecture, a good design, and worked closely on its implementation, my guess is that they would have better results. Not only in the quality of work produced but also other intangibles.

Ever have one developer that is over-worked while the other ten developers wished they could help? Well, not paying attention to Conway’s law is probably the culprit. It is easy to fall into the the argument that: by giving each module an owner we have one throat to choke.

This type of thinking forgets some important items:

  1. People work on projects, someone will take unforeseen time-off.
  2. Dividing up modules does not necessarily divide work equally. Ever have a developer that had a super-easy module and wanders around like the floor like he’s the only one that has his act together?
  3. Unforeseen work presents a challenge on which module it belongs as each module owner will attempt to push the new work onto another. For example, where should certain validations be placed: front-end, middle tier, or at the persistence layer? I bet you the group that with the least political leverage will get this extra work.

So what can we do to break down the social communication barrier? One technique is to implement review practices. Requirements Reviews, Design Reviews, or even Pair Programming, just as long as people are talking.

Remember, a majority of Software Engineering problems can be boiled down to a lack of communication, so don’t avoid communication. The days of the unsociable introvert coder hiding in a dark basement as to avoid human contact is over.