That said, even I like to get some numbers on code, especially unfamiliar code, to help me figure out a few things. For example, I’ve been using CLOC (Count Lines of Code) for years to find out quickly how big a project is and what languages are used in what proportion.

The first metric that’s started to be tracked at work is lines of code added and deleted per release, per author. I’ve occasionally glanced at these kinds of numbers in the past too, and even wrote a little script (git-rank) to get the same kind of info when I was on a code deletion spree. I’ve found these numbers to be useful for getting a general idea of who is most knowledgeable about a project or some files within the project.

However, the numbers can easily be misleading. For example, if someone is committing a lot of style reformats, vendoring code from other projects, or autogenerating documentation, their numbers will be very high but they may know very little about the codebase. For example, for a release to a Rails project I’ve worked on the metrics gathered showed that I had added 248,475 lines and deleted 458,020 lines. That’s obviously suspicious, although it does make me look very active. These are the kinds of numbers that you should dig a little to figure out what’s happening, which is why I wrote my little git-rank script makes it easy to break those line totals down by file, and then exclude files for the next count.

$ git rank v1.1.1..v1.1.9 --all-authors-breakdown --author "Matt Robinson"
Matt Robinson 603061
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail14.json
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail12.json
1 vendor/rails/railties/test/vendor/gems/dummy-gem-a-0.4.0/lib/dummy-gem-a.rb
........
21418 vendor/gems/haml-3.0.13/lib/haml/precompiler.rbc
24953 vendor/gems/haml-3.0.13/test/sass/engine_test.rbc
30038 vendor/gems/haml-3.0.13/test/haml/engine_test.rbc
Matt Robinson 603061

It’s pretty obvious that most of what I did was update vendored gems. If you’re trying to figure out who did the most work between the releases I specified, you probably want to ignore the vendor directory when count lines of code.

% git rank v1.1.1..v1.1.9 --exclude-file vendor
Josh Cooper 4
Nigel Kersten 8
Andreas Zuber 11
Michael Stahnke 11
Jacob Helwig 15
nfagerlund 37
Daniel Pittman 283
Max Martin 418
Nick Lewis 543
Randall Hansen 901
Pieter van de Bruggen 1018
Matt Robinson 1661

Now we’re starting to get a more realistic picture. From here we could dig deeper by listing all the files again for all the authors, and then maybe start excluding lines based on a regex if there were automated changes, and then maybe look at additions vs deletions in the count (I’m summing them together for these numbers).

However, I hope people *never* think they can get the whole picture, or even most of the picture, of a code base and who is contributing the most from something as arbitrary as lines of code counts. I feel like that’s almost too obvious to say, but I’ve heard horror stories of managers who tie reviews to metrics like this. I hope I never personally experience such a thing.

P.S. If anyone tries using the ‘git-rank’ project I mentioned above, please keep in mind it’s a hacky little sick project that is probably got some bugs and you should take the numbers is spits out with a grain of salt. What a weird phrase that is.

Besides building on the open source Puppet projects of Puppet, MCollective, Puppet Dashboard and Facter, we also used a ton of other open source software directly: Rails, Sinatra, BatmanJS, JQuery and many more indirectly. One of our team members pvande was able to contribute a lot of code and help back to the BatmanJS project – we had to since it’s alpha software and we were using it in a commercial application.

As I worked on the project, I sometimes felt sad that it wasn’t being open sourced. I knew the rationalization that at some point the company has to make a product that people will pay us money for, but that wasn’t the rationalization that helped me accept it most at the end. What helped was knowing that by building on top of other open source projects, we ended up contributing a lot back to them. Puppet got bug fixes and small new features to help us manage resources, MCollective got plugin improvements and feedback on how it can better support web app use cases and scale testing, Puppet Dashboard got some CSS cleanup and UI improvements, and BatmanJS got lots of real world use, feedback and code.

Besides, it’s free to try out for fewer than 10 nodes, and since it’s written in interpreted languages, people can view the source code if they really want to. There’s nothing stopping someone from writing a similar thing open sourced, and now we’ve done some of the hard work of improving the platform they would also build on. This does mean that we’ll have to continue to innovate and improve on our closed source features that sell product, but also on our open source platform that enables anyone to build their own features make their life managing systems easier.