Sunday, March 16, 2014

Quantifying Developer Quality

After having written my self evaluation, I've spent some time thinking about the quantifiable assessment of a developers quality. In my self evaluation, one of the major metrics I pointed to as evidence of my efficacy was the number of commits that I made. I did this partly because I made a lot of commits, so this metric was good for me. But additionally, I really think that it is be a good metric by which to judge a developer.

It is true that if you judge purely on number of commits, a developer could game this system by committing changes every time a comment is made or a line of code is written or changed. This could have a negative effect on the code base and make the commit logs opaque and useless. But if this very specific problem is avoided through some kind of monitoring process, then I believe commits can be a good quantifiable metric.

A large number of commits means that the developer is active. Additionally, it shows that the developer is thinking about the problem in small pieces (the parts changed between commits) which I believe is a good style of coding as it allows for easier debugging as well as frequent testing. It also allows other developers frequent access to the code during the development process which they may find useful in their own section of development. Finally, it serves to frequently remind the rest of the group, and oneself, that constant progress is both a good thing and an expectation, moving the overall progress of the project along at a good pace.

For these reasons, I think that commit logs, and the data they contain, are a good and useful objective measure of a developers efficacy.

No comments:

Post a Comment