You know by now that Code Inventory is something of an obsession with me. Like it or not, most of us, whether developers or sysadmins, work in a service industry. It’s fast and furious, and we don’t have time to build features that nobody wants. With sufficient test coverage, there’s no code that can’t be released within a day of pushing to the repository.


Dwight Sipler

A couple of years ago, I showed you how to Visualize Small Batch Sizes with Git by plotting day-to-day the amount of changed source code lines that hadn’t yet been released to production. While this graph gave immediate feedback about the “drift” of development from operations (live), it’s not something easily digested by upper management. What do these guys really care about? It’s all about the releases silly!

Commits are “Units of Work”

Easily understood and very simple to calculate.


Tracking number of code lines changed can easily be misleading with a copy/pasting, package refactoring or adding a new javascript library.

What was in the release?

Clicking on the release shows Pivotal Tracker stories worked on and the actual commit revision ID in github.


The PT story types also give a good indication what the main work type was – user features, chores or bugfixes.

Cause and Effect

Now you’re able to show quite clearly to the organization how often you do releases (and even what your releasing). If tagging releases is ‘crawling’, then you are now at the ‘walking’ phase. What would it take to really stretch our legs out and get ‘running’?

Showing the impact of a release is the next logical step. Did you manage to grow traffic? Has the response time of the site improved? See any more bugs after the release? These are all fairly easy to track, and plotting them as a backdrop to the releases demonstrates the real impact your team is having on the bottom-line.

What other metrics make sense here? What would you expect to see? And what would really be kick ass? Share your thoughts on twitter using the #codeinventory hash tag!