Atakua's Diary

How to make Churn-vs-Complexity chart

Update November 2024: use better scripts to collect and draw the plot.

Michael Feathers’ idea about how to look for maintenance-problematic files in a repository: https://www.agileconnection.com/article/getting-empirical-about-refactoring. In short, the files that contain hard-to-understand code and simultaneously are frequently modified are the primary targets for refactoring. Simplifying them will give the biggest effect on productivity of the team working ith them.

There are cool enterprise solutions like SonarQube which can give this information to you. But I resorted to quick and dirty scripts.

Tools

For each source file, you will need a method to measure its churn (intensity of modification) and complexity (how hard for a human to understand it). Note that instead of files, you can use smaller units, e.g. classes or methods, but that would mean the churn calculation would be more involved.

Complexity analyzer for whole files. In the example below, I use pmccabe for C and C++ files. It can report accumulated cyclomatic complexity for the code. In the simplest case, the lines of code is the metric to look after.
Revision control history for individual files. For files under Git, counting number of commits reported by git log is a good start.

Scripts

Here is a script that I used to apply the aforementioned tools in a loop to all files. Given that it is written in Bash, it is rather cryptic. I was forced to use comments to explain what individual lines do.

#!/bin/bash

set -eu

# Path to the pmccabe executable, change to reflect your installation
CCM=/path/to/pmccabe

# List of all files to analyze, chosen by file extension
FILES=`find . -name '*.[ch]' -or -name '*.cc' -or -name '*.cpp'`

for F in $FILES
do
    # Collect raw output from complexity tool
    CCMRAW=`$CCM -F $F 2>/dev/null`

    # Extract number from the first column
    COMPLEXITY=$(echo $CCMRAW | cut -d " " -f 1

    # Get churn from `git log`
    CHURN=`git log --all --follow -M -C --name-only --format='format:' $F | wc -l`

    # Print line that can be imported to spreadsheet.
    echo $F ${COMPLEXITY} $CHURN
done

Run the script in the top folder of your project. It will write to the standard output.

Save its output in a text file. Format of its lines will be: file-name complexity churn.

Plotting the data

You’ll then need software to visualize the data. From a set of X/Y points with textual labels, draw a scatter diagram with annotations.

I am sure Excel can do that, after some fiddling. But I used Gnuplot.

For example, Gnuplot can render an SVG file for you:

set encoding utf8

set terminal svg mouse standalone dynamic
set termoption noenhanced

set output "churn-vs-complexity.svg"
set ylabel "Churn"
set xlabel "Complexity"
set key off

plot 'data.txt' using 2:3:1 with labels left font "arial,6" point pt 7

Example picture

Below is a picture for the open variant of Intel XED.

Churn versus Complexity plot

As you can see, there is only a handful of files with both high turnover of modifications while simultaneously carrying complex code. The majority of files are gathered at the left bottom corner.

What to do more

Feel free to modify the workflow above to suit your needs. Change the output format, use different complexity tool (e.g. for Python, it might be another mccabe), feed different file extensions to it, or collect churn from a different revision control system.

Keep in mind that file renames may cause the churn to be under-reported. That is why I pass -M --follow to git.

Other things to try: