Collaboration and Code Authorship Credits

In their book “Team Geek”, Brian Fitzpatrick and Ben Collins-Sussman make the following valid point:

The tradition of putting your name at the top of your source code is an old one (heck, both of us have done it in the past [GE: As have I.]), and may have been appropriate in an age where programs were written by individuals and not teams. Today, however, many people may touch a particular piece of code, and the issue of name attribution in a file is the cause of much discussion, wasted time, and hurt feelings.

They don’t elaborate on this much other than to describe the complexity of fairly assigning credit when multiple individuals touch the code over time. Their solution is to assign credit at the project level rather than the code level. Code level authorship can be derived from the version control system if needed. The solution fixes this and many other issues.

In my own experience, I haven’t observed any “hurt feelings,”  but I haven’t managed teams the size of those managed by Fitzpatrick and Collins-Sussman. What I have observed is a reluctance to modify code if an author has been identified in the code. There are many sources for this reluctance. A few are:

  • “It’s not my code, so [insert author’s name here] should be making any changes.” This is, basically, a shifting of burden response.
  • “[Insert author’s name here] is [belligerent/moody/possessive/the alpha geek] and I don’t want to deal with that.”
  • “[Insert author’s name here] wrote this?! What a [hack/newbie]. Why do I have to clean this up?” Responses like this seek to establish blame for any current or future problems with the code.

When authors are not explicitly identified in the code, reluctance to make code changes based on responses like those above are minimized and the current coder can better focus on the task at hand.