Inverse Conway's law

Today I got to present at Devoxx Poland on being agile and managing your architecture.

One of the points I made during the talk had to do with Conway’s Law. For those unfamiliar with it, here it is:

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

This basically means that the code you create is likely to reflect the way the people and teams in your company communicate. For example, banks are usually pretty strict and have a tendency to document things. The code written at banks in turn have the tendency to use SOAP for example, verbose and strict.

The project I’m currently working on has a very agile mindset, we change a lot and have open communication. This reflects in our codebase as well, all the code is easy to understand and easy to change (thankfully!).

But lately we’ve started to move away from our old monolith and we’ve began cutting it up into microservices. That’s when I noticed something odd, which I call the Inverse Conway’s Law (maybe it is Roy’s Law?):

organisations which radically change their system design should expect changes in communication structure Roy van Rijn

What does this mean?

We’ve started to move towards a microservice environment, where each team has a responsibility over a couple of services. They’ve developed it and they own it. This ownership completely changed the culture in our team. Up to now if the monolithic backend was broken or offline, everyone was hurting and everyone wanted to fix this as soon as possible. With microservices, this is gone. The first thing we now do is check which microservice failed. If it isn’t theirs, it is not their problem, it’s someone elses problem now!

This is just one example on how changing the design of our system changed the culture and team dynamic. It is one thing that sounds logical when you think about it, but I didn’t expect this before we started the transition.