Measure Conway's Law with CodeScene
Mel Conway’s astute observation that an organization’s communication structure should be reflected in the software architecture has received plenty of attention over the past years. Part of that is due to the popularization of microservices, which promises natural team boundaries where each team might be responsible for their own service. As such, Conway’s Law is an important principle that drives both organizational and technical decisions. At the same time, the organizational and social side of code is largely left to subjective judgments. What if we could guide those decisions with objective data instead? Follow along and see how you can measure Conway’s Law.
The Social Side of Code
As soon as an organization grows beyond a handful of people, social aspects like coordination, communication, and motivation issues increase in importance. Unfortunately these, well, softer aspects of software development are invisible in our code; if you pick up a piece of code from your system there’s no way of telling if it’s been written by a single developer or if that code is a coordination bottleneck for five development teams. That is, we miss an important piece of information: the people side of code.
CodeScene’s behavioral code analysis helps you fill in the blanks. Behavioral code analysis emphasizes trends in the development of your codebase by mining version-control data. Since version-control data is also social data – we know exactly which programmer that wrote each piece of code – it’s possible to build up knowledge maps of a codebase, as shown in the next figure.
A knowledge map is useful to guide on- and off-boarding, but it doesn’t really help us on our quest to measure Conway’s Law. But it’s a starting point. Our next step is to add the organizational dimension by aggregating individuals into teams. We also want to raise the abstraction level of the analysis and measure on architecturally significant components and sub-systems, as opposed to individual files. CodeScene solves this by letting you specify your architectural boundaries and teams.
For example, if you do microservices, each service would be its own component in an analysis. This gives you a powerful tool to evaluate how well your architecture aligns with your organization, as shown in the next figure.
The previous visualization is based on the actual code contributions of each team. Each team gets assigned a color (look at the color legend to the right in the figure), and the team that has written most of the code gets highlighted for that sub-system. As such, the information is always up to date and you can chose how far back in time you want to go when collecting the data.
The same analysis also lets you measure the coordination needs on an architectural level. This is useful to detect sub-systems that become coordination bottlenecks or lack a clear ownership, as shown in the next figure.
The preceding figure shows a system with a medium overlap between the contributors on different teams. This might be fine – a behavioral code analysis doesn’t judge – but it’s a pattern that deviates from Conway’s Law and, as such, might be worth to look into and understand.
Behavioral code analysis helps you ask the right questions, and points your attention to the aspects of your system – both social and technical – that are most likely to need it. You use this information to find parts of the code that may have to be split and modularized to facilitate parallel development by separate teams, or, find opportunities to introduce a new team into your organization to take on a shared responsibility.
The way developers collaborate is crucial to the success of any system, and this blog post has really just scratched the surface. If you want to dive deeper, you might want to check out my new book, Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, which goes into much more detail with several real-world examples.