Skip to content

Analyse Pair and Mob Programming Patterns

CodeScene's social metrics support organizations that do Pair programming. Here is how it works.

An image from CodeScene showing pair and mob programming annotations in the commit messages.

When we started developing CodeScene, our overall goal was to show that there is more to code than code; we wanted to highlight–and make actionable–all the information that is invisible in the code itself. 

 

One such prominent piece of information is the social dimension of code, like inter-team coordination needs, on- and off-boarding information, and much more. Today, the social analyses pioneered by CodeScene are one of our most powerful features.

 

All of CodeScene’s social metrics are based on the author information as recorded by Git. Because Git only recognizes one author per commit, this may not reflect the social reality of your code if your organization does pair or mob programming where more than one person contributes to a single change. Thus, we have worked hard to also cover those scenarios. Let’s see how it works

 

 

 

Configure for Pair Programming

 

A typical pair programming setup involves committing code from a Git account shared between all team members, and then specifying the actual authors in the commit messages. The next figure shows an example:

 

pair-programming-examples

Pair and mob programming annotations in the commit messages.

 

So in case your organization uses pair or mob programming practices, and you have some annotations in your commit messages, you just need to tell CodeScene about it. This is a straightforward configuration of the specific pattern you use. CodeScene will then extract the author information from your commit messages and adjust the knowledge maps by splitting the code contributions between the actual contributors.

 

Finally, it’s worth pointing out that the author aliases typically used in the commit messages can be resolved by CodeScene too. For example, you might find that most contributors just specify their initials in the commit messages, perhaps as [AT|JF]. If that’s the case, you can use CodeScene’s Developer Identity Mapping to declare AT and JF as aliases of the corresponding developers. Here’s an example:

 

resolve-alias

Modify the name of any author to resolve aliases.

 

With that configuration in place, you’re ready to explore the knowledge maps over your codebase, pair programmed or not.

 

knowlede-map

Example on a knowledge map that lets you explore the main contributors to each module.

 

 

 

Try it Yourself

 

The pair programming support is available in our on-premise version, and we’ll add it to the Cloud Version soon too.

Adam Tornhill

Adam Tornhill

Adam Tornhill is a programmer who combines degrees in engineering and psychology. He’s the founder and CTO of CodeScene where he designs tools for code analysis. Adam is also a recognized international speaker and the author of multiple technical books, including the best selling Your Code as a Crime Scene and Software Design X-Rays. Adam’s other interests include modern history, music, retro computing, and martial arts.

Elements Image

Subscribe to our newsletter

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Semper neque enim rhoncus vestibulum at maecenas. Ut sociis dignissim.

Latest Articles

Change coupling: visualize the cost of change

Change coupling: visualize the cost of change

Code can be hard to understand due to excess accidental complexity. Or, it can look simple, yet its behavior is anything but due to complex...

CodeScene's IDE Extension brings CodeHealth™ Analysis directly into your editor

CodeScene's IDE Extension brings CodeHealth™ Analysis directly into your editor

We've just launched an IDE Extension for VS Code, helping developers tackle code complexity within the editor. Read more and try it out!

Example of a functional programming refactoring pattern

Example of a functional programming refactoring pattern

In this post we'll demonstrate an example of a functional refactoring pattern.