I’m always curious about how, why and wherefore when it comes to getting code written. We had a software engineering undergrad course, I’ve read some of the classic books (Brooks, DeMarco/Lister, etc) with various metrics, and I’ve always kept an eye out for ways to measure my own productivity. For your and my amusement, here’s a work project, in Python / Twisted, with Git repository metrics from a commercial product called FishEye:

[caption id=”attachment_1259” align=”alignnone” width=”282” caption=”Code was from October 2009 through April 2010”][/caption]

[caption id=”attachment_1257” align=”alignnone” width=”281” caption=”Bursts of productivity on the week view”][/caption]

The weekly view makes sense - we run an agile process here, so those correspond to ‘iterations’ of development.

Here you can see the code accumulate:

[caption id=”attachment_1256” align=”alignnone” width=”284” caption=”Top graph is total lines of code.”][/caption]

Last, and most interesting in my opinion, is the commits by day:

[caption id=”attachment_1258” align=”alignnone” width=”276” caption=”Thursday is my best day??”][/caption]

I would never have guessed that Thurs was my best day in terms of commits.

(Note the time graph is broken, as FishEye is converting timezones incorrectly. I’m not really pushing code at midnight.)

This is a small-to-medium-sized project, less than 5KLOC, with basically one developer, so the usual caveats about anecdotes apply. Still interesting to me. I’ll repost here in a few months, we’re now collaborating on a larger, shared project and it’ll be interesting to see what that does to the stats.

Update 5/26: The code is fairly complex, a set of a dozen or so modules communicating over AMQP to implement an OpenDAP cache accessed via HTTP proxy and/or web interface, and also includes a decent set of unit and integration tests.