AvocadoSoftware.com

Software For Hardcore Developers
Welcome to AvocadoSoftware.com Sign in | Join | Help
in Search

Derick Baileys old blog archives - go to derickbailey.com for new contents

Collective Code Ownership

The subject of code ownership came up in a conversation, and I wanted to share my thoughts.

In general, my policy for code/project ownership is that every developer on the team owns every line of code in the project, once that code is committed to subversion.

An individual or small team may be assigned to an area of code for development and/or corrections, and during the times that they are assigned to the area and actively working on it, that person/team will have some authority over the code. If a person not on the team sees an issue or has some advice/corrections, then the person should make the suggestions to the team that is currently engaged in that area and both parties should discuss it to come, to come to a satisfactory conclusion. Once a functional area is committed, though, and the major work is completed, that code now belongs to the entire team.

If you see some code that needs to be fixed, refactored, or otherwise changed to support some features and functionality that you need, please feel free to make the changes that are needed. I only ask that you keep the original developer(s) informed so that everyone knows what is going on and why. Perhaps the original team knew about an issue that you did not, or the other way around. Either way, we all need to ensure that communicate changes being made so that the person who wrote it originally is not surprised when they go back to the code and it is different than they remember.

There are a lot of benefits to team-ownership of code. First and foremost, it forces us to put our ego aside and listen to our team members – understand that you do not “own” the code but you are simply exercising a temporary authority over the code that you are currently developing. Secondly, it prevents code bottlenecks. If one person “owns” a chunk of code and is busy on another section, waiting for them to get to the area you need fixed is a bad idea and slows you down. If we all own the code collectively, you can go in and make the changes that you need. The end result is also better code from every developer. Being conscious of collective ownership will help remind you to code for easy readability/maintainability and the communicative nature of collective ownership also allows for a strong learning environment – if I see a chunk of code that needs fixing or can be written to be more flexible for what I’m currently doing, discussing it with the original developer will improve that developer’s code skill.

Long story short:

  • Communicate your needs/changes with the original developer(s)
  • Don’t be afraid to change code that you did not write
  • Don’t change something “just because”, be sure that there is a valid need to change it

 

Resources:

Published Friday, June 29, 2007 12:49 PM by dredge
New Comments to this post are disabled

This Blog

Post Calendar

<June 2007>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

Advertisement

News

this is my old blog archives - go to http://derickbailey.com for updates

Syndication

Advertisement

Powered by Community Server, by Telligent Systems