Seeing the Team in the Code

Conway’s Law reads:

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

While it has served as a fun adage since its introduction in 1968, recent studies show evidence that Conway’s Law exists. One such study was brought to us by the legendary Victor Basili, who has been contributing to this field for many years,  and Nachiappan Nagappan, who has an ever-increasingly impressive body of work himself. In their study they propose some metrics that one might make of the organization and their implications to the code.

There are many measurements we can take of our code;  we can trend the values over time. Although certainly not limited to this list, things we can measure about code include:

DSQI (design structure quality index) Function Point Analysis Halstead Complexity Instruction path length Classes and interfaces Lines of code per module Program size (binary) Weighted Micro Function Points

Balanced scorecard Bugs per line of code COCOMO Code Coverage Cohesion Comment Density Connascent Software Components Coupling Cyclomatic complexity (McCabe’s complexity)

Software Package Metrics from Bob Martin Number of Classes and Interfaces Afferent Couplings (Ca) Efferent Couplings (Ce) Abstractness (A) Instability (I) Distance from the Main Sequence (D) Package Dependency Cycles

If Conway’s Law is indeed true, we should be able to observe trends and patterns in  these measures that correlate to specific patterns and trends in the organization that creates the code itself. I can even predict some correlating patterns such as:

Assertion

Distributed teams in which all team members live in different time zones will create code with lower Coupling than co-located teams.

Reasoning

Distributed team members tend to communicate via functional boundaries of the application architecture. Instead of having to explain business logic expressed in a code behind file, team members look for repeatable ways to compartmentalize discussion with team mates, making design discussions more efficient.

Further, there is less trust within a distributed team compared to a co-located team. This leads to developers creating more extension points in the application such they can guarantee “my part works” when integrating.

This causes the evolution of a command pattern within the application (for instance).

Pretending this theory holds water, we can further assert that patterns of team structure will produce specific patterns in code. If we had a database of measures like those provided here, and a correlating understanding of what practices and structures were used by the teams who created the code, we might be able to project. We might therefore assert:

Given a Development Team in which (this pattern exists)
Then (this measure)
Will (observed values trend)

Given a Development Team in which team members are co-located and work in the same room
Then the number of Interface instances per package
Will be lower than 1 in 10 class files.

or something…

So Tell Me

What code measures do you favor and why?

What correlations between communication patterns and code can you predict?