Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Assuming you are working for a company or in a team of developers, is the code bound to the person who did it? When someone develops a particular functionality or an area of the application, is this person the only one who can, is allowed or is just able to make changes to it?

I personally think that a well-done piece of code or program should be easily modified by any programmers, but what about what you see in your environment?

At my work, I'd say that the majority of the code can be modified by anyone (that's what coding standards are for right?). There are some things though that are 'property' of some coworkers like the module that handles the pay or some important functionality of the production module (we are developing an ERP system).

What about your work place? Am I the only one living this?

share|improve this question
8  
Every organization is different. Are you doing a survey? –  user8685 Feb 3 '11 at 23:44
6  
At my place of work, if it's not done my way, someone gets bitch slapped....which makes it really funny when I'm the one that did it wrong. –  Crazy Eddie Feb 4 '11 at 0:09
    
Possible duplicate of programmers.stackexchange.com/questions/33460/… –  Jason Baker Feb 4 '11 at 2:12
    
You describe code ownership. It strongly depends on the culture how important this is, but you should always discuss changes with the person who will need to fix it if you break it. –  user1249 Feb 1 '12 at 15:16
add comment

12 Answers

up vote 26 down vote accepted

If the programmer is tied to their code that is bad.

Code is the intellectual property of the employer.

Obligatory car analogy: Would you want to own a car that only Luigi can fix ?

Corollary: The last person to touch a subsystem knows it best, and may be the best to change it again.

Code only the developer can understand fails the simplest test for maintainability (80% of the costs of the project is maintenance)

And lastly, what is the truck number of your project ? How many people need to get hit by trucks to ruin the project ? A truck number of one is a very bad thing from a risk mitigation point of view. (More likely than a truck is that a 'critical' person might quit)

share|improve this answer
1  
+1 for "Would you want to own a car that only Luigi can fix?". BTW, we call it "Lottery number". –  nikie Feb 4 '11 at 8:19
1  
We call is "Bus number". –  cha0site Feb 1 '12 at 19:09
    
I live in Australia, most trucks (lorries) are at least a B double ( two trailers) and we have road trains of 4 trailers with one tractor unit. And wher I live buses are more stationary on the side of the road than moving. –  Tim Williscroft Feb 1 '12 at 23:37
    
+1 Risk management 101. Actually, I'd prefer the use a factor instead of a number as it is usually seems less arbitrary. I.e. the risk or probability of failure if a key team member somehow has left the project regardless of the situation if they've been hit by a bus/lorry/airplane/tuk-tuk, recently shark attacked or eaten up by a lion. –  Spoike Feb 2 '12 at 9:47
add comment

I've worked at places where the code though not technically bound to a single person effectively is, and places where it is mostly bound to a team.

In the first of the two types, I hated it. Knowledge was hoarded and it was extremely difficult to get anything of value done. People took their code (in my opinion) far too personally. That is, a suggestion for improvement so that others could better understand it was perceived as a personal attack and strongly resisted.

At the second of the two types, I enjoyed it much more. No module had the feel of "private" property that no one else dared to tread upon even though each team often had their go-to guy for different parts. Knowledge was shared between people in the teams so that no one person was critical. Sharing of the knowledge was done in many ways, including but not limited to ...

  1. Code reviews before every checkin to find bugs and share implementation knowledge.
  2. Standards that insisted upon module and function comments describing intent.

Hope this helps.

share|improve this answer
add comment

This question reminds me of this (deleted answer stating "Your job is to put yourself out of work.")

And that's pretty much what I think.

Code being tied to individual programmers is a job smell (but can be either individual or organisational - depending on who/what is encouraging it to be like that).

share|improve this answer
add comment

While it makes sense for coders to specialize, there is a huge risk in depending on just one person's knowledge, particularly in a huge project. Sometime new people come in waves (say 1995 was a good year, so we hired 10 new coders) and thus sometimes leave in waves (been there for 5 years, time to move on).

If you lose 3 specialists in 3 months (which I have seen happen), you are pretty much screwed.

There are many compelling reasons why several people might want to work on the same project. Scrum has a concept of "pairing".

share|improve this answer
    
No, that's XP. Scrum as it is does not include pair programming (although it can incorporate practices from XP or other agile methods). –  Péter Török Feb 3 '11 at 23:58
    
@Péter Török, Scrum also has a concept of pairing, although it is not a major theme. It is probably different from pair programming, because one can pair with a dev, qa, etc. –  Job Feb 5 '11 at 15:15
add comment

It differs from place to place, team to team, project to project.

But in general I'd say what works best is when code is bound to a team rather than a person. When bound to a team there's a group of people all able to edit and make changes to it so it doesn't just get the input from a single person and nothing's too heavily reliant on one person. But it's not at the other extreme either where anyone can do whatever they want to it, it's constrained within the boundaries of people who (hopefully) know the code and know what they're doing.

When it's constrained to a single person then that's bad. They may resist good changes to their code, they may have coded in a way no-one else will understand, they may be leaving the code base in a mess and they may be making mistakes that wouldn't have gone unnoticed given a second opinion. Of course, not all those points are automatically true when there's just a single maintainer, but they're generally far more likely.

share|improve this answer
add comment

For most codebases, yes, coders should be interchangeable.

However, the concept of code ownership is beneficial when a particular programmer has in depth technical or domain knowledge over a subset of the codebase. In this scenario, it may be fine for other programmers to work on/with the "owned" code, but the owner maintains oversight, usually through peer code reviews.

share|improve this answer
add comment

It should not be. At my work we have a responsibility matrix spreasheet that shows each team members strength (scale of 1-5) in major technical and business area. Then you have a development plan so that those with 1-2 in one area becomes 3-4 by the end of the year.
In practice I find that although competent developers can pick up new code easily it is the business rules/processes and data behind the code that is difficult to learn and lets some people get attached to the code they originally developed.

share|improve this answer
add comment

In general anybody (on the team) should be able to edit any code (owned by the team). You don't want different teams modifying each others code (though they are not out to get each other each team may have different goals so what is in the interest of one team may not be in the interest of another).

Only the team that owns the code should change it (as they will have to maintain it) and other teams should not branch the code either (as that will lead to other problems down the road).

Now this may be a general principle but certain pieces of code may be owned by an individual (for historic reasons usually; but say it was really hard to get correct. It requires specific domain knowledge etc). It does not mean that other people can't fix bugs in it, but rather that you should make sure the owner has a chance to check it before anything is changed.

share|improve this answer
add comment

Based on my experience and my own attitudes, programmers are bound to their code. They aren't bound by policy or by corporate mandates; instead, they're bound to it as creator to creation.

I personally find it tough to let go of my code and let others work with it. No two people do things the same or use the same techniques, and there is a certain artistic and engineering pride that goes into a feature or product.

In most cases in my organization, the developer who built the feature will generally maintain it, but not because of the above maternal/paternal reasons, but because that developer generally has a better understanding of that feature.

Over the last few years, I have learned to let go of the minor details and try to stay focused on the goals of the project. It's only code, and the end-users and even management will never, ever see it.

share|improve this answer
add comment

I've seen this happen more than once, and i think it's bad.

The reasons are the same as for the lack of documentation, refactoring, unit tests: "we don't have the time right now, to do it better", which of course is like saying "i don't have time to sharpen the axe, i am busy cutting wood".

share|improve this answer
add comment

As for who 'owns' the code, If I would be tied to my code at work, it also means I own the intellectual and commercial rights to do anything with it. In most companies, that is most definitely not the case. This means if my company owns the code, they are responsible for it. I am just an employee who designs or maintains the code. If I get sick, get a burnout or worse, someone else must take my place anyway.

As for being tied to the code, I take much pride in my work, and when something works bug free and fast, and keeps working that way I feel that warm fuzzy feeling. But on the other hand, when someone modifies my code to be better, or someone redesigns it or offers better ideas, I am all for it. I am a realist, and I do not mind someone touching or commenting my code. That means we can discuss better alternatives, either I learn something from it, or my colleague learns something new. In my opinion everybody can get something out of it that way.

share|improve this answer
add comment

In most cases there are always a team of developers for a project but it purely depends on the revenue the project is earning. If the scope of the project is more then there are sure to be more developers and there would be more of knowledge transfer compared to project that has lesser revenue.

The good team leader or project manager ensures that knowledge transfer takes place from time to time among his team.

In my personal experience, I always ensured proper knowledge transfer to my fellow team mates which

  1. Ensure project stability.
  2. Improvement in code quality through peer reviews.
  3. Helps in handling any situation (crisis).

Enjoy working as a team. Good luck.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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