Social Networks
The Social Network Analysis gives you a heuristic on the coordination
needs between developers on different teams. The idea is based on
Conway’s law - a project works best when its organizational structure is
mirrored in software. Using the Social Network Analysis, you now have
a way to ensure that your organization matches the way the system is
designed with respect to the work the developers do.
The Social Network Is Build from How the Code Evolves
The social network paths are mined from how your codebase is developed.
Fig. 41 illustrates how we build your social network.
Every time two developers have worked in the same part of the codebase,
any part, they get a communication link between them. The more often
they work in the same parts of the code, the stronger their link. Note
that Empear Enterprise filters developers with too weak communication
paths since they would clutter the visualization (you can change the
threshold as described in the Repository Configuration
Guide).
Define Your Development Teams
The social network lets you identify developers that should be close
from an organizational perspective. The visualization above is from an
open-source project without any formal organization or hierarchy. Thus,
all developers belong to the same team and the network looks like a
circle. If you hover over a developer, you highlight their peers that
work in the same parts of the codebase.
While a flat visualization like this may provide insights, for example
on key developers, it gets much more interesting if you add teams to the
visualization as described in Configure Developers and
Teams.
As soon as you define teams, sub-sequent analyses will organize the
developers in the network by their respective team. That lets you
uncover the ideal communication paths between developers in your
organization. Please note that there’s no guarantee that these
communication paths exist in the real world! That means you want to
compare your organizational chart with the information below. Any
discrepancies should be addressed.
Align Your Architecture and Organization
In a perfect world most of your communication paths would be between
developers on the same team. That is, the teams have a meaning from an
architectural perspective; People on the same team work on the same
parts of the codebase. They share the same context, know each other and
have a much easier time coordinating their work.
However, sometimes the world looks radically different. Have a look at
social-network-anti.
The visualization in social-network-anti shows an organization with severe coordination
problems. Since the data has been made anonymous to protect the guilty,
you cannot read the names of the teams or developers. But you still see
that the organization has four teams with a high degree of inter-team
coordination between virtually every developer. In practice, this isn’t
an organization with four different teams. Rather, it’s an organization
with one giant team of 29 developers with artificial organizational
boundaries between them. The resulting process loss due to coordination
needs is likely to be severe and lead to inefficient development,
quality issues and code that’s hard to evolve.
Social Networks¶
The Social Network Analysis gives you a heuristic on the coordination needs between developers on different teams. The idea is based on Conway’s law - a project works best when its organizational structure is mirrored in software. Using the Social Network Analysis, you now have a way to ensure that your organization matches the way the system is designed with respect to the work the developers do.
The Social Network Is Build from How the Code Evolves¶
The social network paths are mined from how your codebase is developed. Fig. 41 illustrates how we build your social network.
Fig. 41 An example of a social network in code.
Every time two developers have worked in the same part of the codebase, any part, they get a communication link between them. The more often they work in the same parts of the code, the stronger their link. Note that Empear Enterprise filters developers with too weak communication paths since they would clutter the visualization (you can change the threshold as described in the Repository Configuration Guide).
Define Your Development Teams¶
The social network lets you identify developers that should be close from an organizational perspective. The visualization above is from an open-source project without any formal organization or hierarchy. Thus, all developers belong to the same team and the network looks like a circle. If you hover over a developer, you highlight their peers that work in the same parts of the codebase.
While a flat visualization like this may provide insights, for example on key developers, it gets much more interesting if you add teams to the visualization as described in Configure Developers and Teams.
As soon as you define teams, sub-sequent analyses will organize the developers in the network by their respective team. That lets you uncover the ideal communication paths between developers in your organization. Please note that there’s no guarantee that these communication paths exist in the real world! That means you want to compare your organizational chart with the information below. Any discrepancies should be addressed.
Align Your Architecture and Organization¶
In a perfect world most of your communication paths would be between developers on the same team. That is, the teams have a meaning from an architectural perspective; People on the same team work on the same parts of the codebase. They share the same context, know each other and have a much easier time coordinating their work.
However, sometimes the world looks radically different. Have a look at
social-network-anti.Fig. 42 An example of a social network anti-pattern.
The visualization in
social-network-antishows an organization with severe coordination problems. Since the data has been made anonymous to protect the guilty, you cannot read the names of the teams or developers. But you still see that the organization has four teams with a high degree of inter-team coordination between virtually every developer. In practice, this isn’t an organization with four different teams. Rather, it’s an organization with one giant team of 29 developers with artificial organizational boundaries between them. The resulting process loss due to coordination needs is likely to be severe and lead to inefficient development, quality issues and code that’s hard to evolve.