Neil Kandalgaonkar

hacker, maker of things

Graphing activities in a short project

I recently finished a short one week project, which took about a month. I wondered exactly where the time was going.

There were only a few hundred commits, so it was possible to tag them all. Here are the results:

Stack graph of tagged commits

This project happened to tie together a lot of different APIs, and I was learning a number of new technologies, so I wondered if that was what was burning up time. Or if I just hadn’t been working consistently, or something like that.

So I decided to tag the commits by what kind of work they were:

  init for just starting out, downloading a library and getting it set up

  explore for stumbling around with the library, making the simplest things work

  extend for when one is getting more familiar, and creating with few impediments

  devsupport for any work that was just related to development, like fiddling with .git or resolving merges. I was working with an intern and he wasn’t skilled at dealing with this, so there were setbacks

  refactor for work which didn’t add functionality, but just made everything neater

  debug for any commits solely made to debug a problem (often in production)

  document for documentation.

There’s no scale on the y-axis because it’s made up. I wanted it to represent units of psychological work, which is sort of related to number of commits, and sort of related to amount of code I wrote. So what you see here is a stack graph of the logarithms of the sizes of commits, summed for each category for each day. It’s not particularly valid, but I needed some way to make a massive, automated refactoring visible in the same way that exploratory programming would be.

Preliminary insights: the start was much slower than I remembered. I knew the start date from the first commit, but we didn’t really get going for quite a while. Less time was taken up refactoring things than I thought; for the most part the work was rather steady. And it only happens in the last stretch, which seems appropriate.

We had “init” and “explore” work all through this project due to the number of APIs and my unfamiliarity with them, and that does seem to be associated with lower productivity in terms of lines of code.