TITLE: The Growing Buzz around Empirical Analysis of Repositories
AUTHOR: Eugene Wallingford
DATE: March 04, 2011  5:25 PM
DESC: 
-----
BODY:
This has turned into a recurring theme, due to a
hopeful trend out in industry.

Last semester, I wrote a bit about
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-10.html#e2010-10-06T11_24_04.htm">
   studying program repositories</A>
as a way to understand how programmers work.  Then
last month, I wrote about
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-02.html#e2011-02-11T16_15_44.htm">
   simple empirical analysis of code</A>,
referring to Michael Feathers's article on how we
can learn a lot about our program's design by
<A HREF="http://michaelfeathers.typepad.com/michael_feathers_blog/2011/01/measuring-the-closure-of-code.html">
   looking at our commit log</A>.
Feathers went on to write a short note about
<A HREF="http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=16679&tth=DYN&tt=siteemail&iDyn=2">
   getting empirical about refactoring</A>,
in which he expanded on the idea of looking at our
code to understand its design better.

Now we have
<A HREF="https://github.com/chad/turbulence">
   Turbulence</A>,
a package for pulling useful metrics about our code
out of a git repository.  The package began its life
when Feathers and Corey Haines wrote a script to
plot code churn versus its complexity.  Haines has
<A HREF="http://programmingtour.blogspot.com/2011/03/turbulence-measuring-turbulent-nature.html">
   written a bit about the Turbulence project</A>.

It doesn't end there.  Developers are using Turbulence
and adding to its code base.  Feathers's has called
for a
<A HREF="http://michaelfeathers.typepad.com/michael_feathers_blog/2011/03/data-rich-development.html">
   renewed focus on design in the wild</A>
using the data we have at our fingertips.  The
physicians have begun to heal themselves, and they
are leading the way for the rest of us.

One nice side effect of this trend is making available
to a wider audience some of the academic research that
has been done in this vein, such as Nagappan and Ball's
paper on
<A HREF="http://research.microsoft.com/apps/pubs/default.aspx?id=69126">
   code churn and defect density</A>.
(I had the pleasure of meeting Ball when we served on
a panel at OOPSLA several years ago.)

As many people are saying,
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-02.html#e2011-02-10T16_04_17.htm">
   we swim in data</A>.
We just have to find ways to use it well.  I remain
ever amazed at what our tools enable us to do.

All this talk about git has me resolved to go all the
way and make a full switch to it.  I've dabbled with
git a bit and consumed a lot of software off GitHub,
but now it's time to do all my development in it.
Fortunately, there are a few excellent resources to
help me, including the often-lauded
<A HREF="http://gitimmersion.com/">
   Git Immersion</A>
guided tour by Jim Weirich and crew. and Scott
Chacon's visually engaging
<A HREF="http://www.slideshare.net/chacon/getting-git">
   Getting Git</A>
slidedeck.  My trip to to SIGCSE and the spring break
that follows immediately after can't come to soon!
-----