10

I have long believed (and heard from others) that keeping track of commit statistics, such as how many commits each developer makes per day, is harmful to the development process. The reason seems obvious - developers will commit in smaller increments, maximising their commit-per-day number, but making it harder to bisect (perhaps all their intermediate patches won't leave the repo well formed) and harder to work with the commit history (a change will suddenly be in multiple commits, instead of just one, reverting a patch is harder etc).

Are there any studies that show commit statistics are harmful? Any elegant and well-argued article on the topic? Equally applicable would be anything about why measuring the wrong thing leads to people optimising the wrong thing, which this problem is just a special case of.

Improve this question
6
  • 8
    "Any elegant and well-argued article"?? Your question is elegant and well-argued. What more do you need? You provided ample evidence that the numbers are trivially gamed and therefore useless. What more do you want than your elegant and well-argued question?
    – S.Lott
    Commented Jan 29, 2012 at 14:20
  • Developers need to have tried working with finding and fixing bugs in large-commit and small-commits scenarios to see the differenc.e
    – user1249
    Commented Jan 29, 2012 at 16:15
  • I don't think gathering the statistic is harmful in itself but using it to evaluate programmers would be. Our VCS gathers that info, along with a myriad if other stats, and its available to the whole team but we hardly ever look at it. So no, gathering the statistic isn't harmful.
    – MarkJ
    Commented Jan 29, 2012 at 17:21
  • I'm not debating big vs small commits here (I'm personally a small commit kind of guy), merely external pressure to change the commit size to to fake a statistic (which can never be good). I'm ideally looking for somewhere I can point others at, so I don't have to make the argument myself :)
    – Neil Mitchell
    Commented Jan 29, 2012 at 21:24
  • 2
    I believe that this Dilbert comic makes the case as well as anything I've ever seen.
    – ebneter
    Commented Jan 30, 2012 at 20:19

2 Answers 2

Reset to default
8

http://www.mit.edu/~hauser/Papers/Hauser-Katz%20Measure%2004-98.pdf

Is this the kind of thing you're looking for? There are thousands of "you only get what you measure" articles found by Google.

Improve this answer
1
  • 1
    Normally I wouldn't upvote a basically link-only+no-excerpt answer, but in this specific case I find it fine, since "the answer" would just be the question itself anyway.
    – o0'.
    Commented Aug 1, 2014 at 19:23
6

It is a fun statistic to measure, but no more useful than recording the number of hours a developer worked during the week.

For one, it doesn't take into account code quality. One developer might be committing continually as he keeps on fixing bugs in his code. This would show large number of commits, compared to a developer who commits one chunk of finished, polished code. You wouldn't think that the guy with the bigger commit count was the better developer.

Similarly, someone who slacks off and surf SO all day long only to commit once a day would have the same commit count as the dedicated developer who spent all day coding only to do a final commit at day-end to keep his code safe.

If you have a system where lines of code committed is counted, the guy who goes through the source files 'refactoring' every curly bracket to his preferred style will have a huge value. The guy who did the 1-line sup-important bugfix will barely show up.

So it doesn't make any meaningful statistic even if developers don't game the system. It should provide you with nothing except a pretty graph. However everyone likes stats so I'd say keep them, but don't use them for anything other than fun.

Improve this answer
4
  • While your opinion is interesting, the actual question seems to be "are there any studies...?" which your answer doesn't address.
    – Bryan Oakley
    Commented Jan 29, 2012 at 15:46
  • "number of lines". It may take several days to research a problem that will eventually result in a single line patch.
    – user1249
    Commented Jan 29, 2012 at 16:17
  • 5
    just a tale, but a classic one.
    – Wrikken
    Commented Jan 29, 2012 at 16:48
  • This "several days" (or at least several hours) of research resulting in a very important but single line fix happens pretty often in my experience.
    – Johan
    Commented Jul 13, 2016 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.