7

There are multiple ways of tracking code ownership (i.e., collective, team or individual).

In case of team or individual ownership, how do you:

  • track ownership?
  • deal with situations when dev leaves or team splits/re-organizes for new projects?
gnat
  • 21,442
  • 29
  • 112
  • 288
Asad Iqbal
  • 265
  • 1
  • 6
  • What is the company's (employer's) relationship to the code? – jcmeloni Mar 17 '12 at 02:03
  • Assume that it is a software company – Asad Iqbal Mar 17 '12 at 02:19
  • So this is not a question about legal code ownership but rather reassignment of work? – jcmeloni Mar 17 '12 at 14:23
  • How about maintaining this information outside the code? i.e., for each employee (or pair of employee) a list of classes, documents, sites and production hardware (if he was maintaining). And when he leaves, we exactly know what we need to transfer. – Asad Iqbal Mar 20 '12 at 17:38
  • That would be a different question, perhaps better suited for Project Management SE depending on the focus, about maintaining a knowledgebase for the team (or company). – jcmeloni Mar 20 '12 at 17:53
  • related: [Is individual code ownership important?](http://programmers.stackexchange.com/questions/33460/is-individual-code-ownership-important), [Should you write good documentation and clean code to increase the “Bus Factor”?](http://programmers.stackexchange.com/questions/111846/should-you-write-good-documentation-and-clean-code-to-increase-the-bus-factor) – gnat Mar 20 '12 at 17:57
  • @gnat either of individual or team ownership is suitable. i am not in favor of collective ownership for large projects. Otherwise, no one will be ready to take responsibility of a failure, which means no one will step ahead to fix a uninteresting bug even if they know about it; because they will not assume responsibility. – Asad Iqbal Mar 20 '12 at 22:51

3 Answers3

5

As a team leader, you should always plan for someone leaving / getting hit by a bus. People implement this in many ways: Pair programming / buddy testing and so on. Sole proprietorship in a corporate environment is detrimental to both the company and the developer. The developer can never be promoted because he is too important to move away from this, or worse, could be promoted too high, just to keep him around and will be the first one to be laid off in lean times. Its a lose lose scenario.

Having said that, whenever teams split, I have seen serious knowledge transfer sessions / recorded presentations / documentation touch ups happen.

Subu Sankara Subramanian
  • 2,438
  • 15
  • 23
  • I agree with all of above and its benefits, but how do you track it? Every time some help is needed for a component owned by another team 'asking around for the owner' cannot be the solution. Moving up the management chain and then reaching the team lead to get hold of the appropriate engineer is not a scalable solution. – Asad Iqbal Mar 17 '12 at 02:55
  • @AsadIqbal Sometimes moving up the chain is the only way. I have seen some projects where suddenly the whole team gets poached by another company / leaves to start their own company - and it lands on the manager's head to figure this out. Kind of makes it that much more important for the management to know their code base and teams very well don't you think? :) – Subu Sankara Subramanian Mar 17 '12 at 03:02
  • 2
    "Hit by a bus"... I prefer the variant "Hit by the Lottery Jackpot" ;) – Jeroen Mar 18 '12 at 10:15
  • 1
    @Asad, if you start by looking up the last person who made a change to a component in source control, "asking around" scales better than you might think. A technological solution isn't necessarily the best one. – Karl Bielefeldt Mar 18 '12 at 13:25
2

This is a great time for a code review and adding documentation to the code. Often, programmers will write large chunks of code with the intent to clean it up and make it readable later. Code reviews very much encourage the cleanup and allow others to view and learn the code.

If there is one person responsible for a region of code, have them formally hand off the code to another person -- if possible -- through pair programming, code review, or mentoring. Trouble is, if you haven't done this before you lose a developer, you may never get the chance. This can be a downfall of individual ownership.

Owen Johnson
  • 621
  • 1
  • 5
  • 10
-1

You may use the version control system to keep tracking of code ownership. I'm not sure if you can do this with all VCSes or not, but for the git/Gerrit pair, you can put the name and contact details of the code owner in the description field. For other systems you can consider creating a text file (let's call it OWNER.txt) within the module that provides the same information; so that, if the developer can checkout the code, she already has the contact details of the module owner. If you create a template, you can also script it, so that you get an up to date list available whenever you need it (even create a web page that displays the code owners).

Developers leaving the project happens all the time and I don't see a direct link to this problem, but with my proposed solution, you can simply change the module description (or the OWNER.txt file for that matter).

some user
  • 103
  • 3