A strong Agile concept is Joint Code Ownership - no single member of the team owns a piece of code, but rather the entire team. This means the code is up for editing, improvement, refactoring...
How do you promote this concept? How do you deal with a team member that has trust issues regarding his code, and remains suspicious of other people messing with it?
I've used a shared repository and expectations that code can be checked out by anyone. A culture that explicitly reinforces this is essential. It needs to be stated. In reality, though, senior developers have more ownership than junior developers. In cases where opinions differ, the more senior developer usually has final say in what code is acceptable.
A quick way to do that is through pair programming. Short iteration cycles where a developer is only working on a given area of code for an iteration helps as well. An implicit need in Agile development is trust. I can't really give a lot of advice there.
I can't say I've been in quite that situation, luckily for me, but I'll tell you what often happens at my current job.
There, we have people who are more familiar with a certain portion of code, often because they wrote the original (or the most recent refactoring). Then, when someone makes a (usually non-trivial) change in that area, they make sure to have the "expert" review it. Often, if it is a tricky undertaking, they'll double-check their approach with that person before coding it up.
Having everything go through code-review helps as well, as that gets more people familiar with more parts of the code, and also gives people more of an ownership stake in the other areas, since they made suggestions and critiques.
If all that fails, you can always try demonstrating the benefits of the new code. Or point out that you saved them some time fixing the bug. But if you try to go this route to gain trust, be pretty sure you're getting it right, or it will just reinforce their suspicion.
Edit
jpoh asked in the comments:
Although practically, the person who is most familiar with a particular section of code would normally be the one who codes any changes, no?
The original author will often be the one to make changes, especially in the first month or so after the code has been written. However, there are a number of reasons why that might change:
For a little more background on where I work now, our current codebase was originally developed about 6 years ago, with many algorithms from it lifted from an even earlier project. Many of the developers have been around since then, with plenty of chances to correct each other, and the attitude of openness to bug fixes is (hopefully) transferred to new hires as they come on and become acclimated to our environment.
So far, we also appear to have programmers genuinely interested in improvement, and ones that usually like seeing a simpler, nicer, or more elegant way to solve a problem -- or, they'll explain why that way won't work for this problem. That helps as well.
How do you promote this concept? How do you deal with a team member that has trust issues regarding his code, and remains suspicious of other people messing with it?
Two ways spring to mind:
The principle of this is that if someone is going to get touchy about their code then they clearly have no intention of working with the team. Pair Programming should isolate this pretty quickly.
The promotion of Joint Code Ownership is something that should be subtly emphasised throughout the day. Drive discussion towards pieces of code that one person has written to see how others would perform the same tasks differently, push Pair Programming on those that don't want to fall in line/those that need a mentor, reward the team when things go smoothly, etc.
To promote code ownership in a team, you have to get team buy-in beforehand.
If you don't have team buy-in, then why are you trying to do it? If you do have team buy-in, then you can try sitting down with the original code owner to prove objectively that the code has been improved.
FWIW, my current company doesn't do common code ownership. Developers aren't plug-compatible components, and pride of ownership is an important factor in the psychological make-up of many developers. Mess with that at your peril.
Even with team buy-in, remember that changing code isn't just about the code. If some members of a team don't understand the domain subtleties, they shouldn't be editing certain sections of code. Projects are about getting the business right, over and above any agreements on code ownership.
One thing is language. We never say "your code" or "my code," and will correct anyone who uses those words. If you must, you can say "that piece of code I wrote originally."
As to Mr. Hands Off My Code, he needs to understand that letting others modify "his" code only strengthens the entire codebase. If someone finds a bug in "his" code, it's not a reflection on him, but the entire team. The entire team shares the glory, and the shame.
Fixing each other defects is a good start but I have noticed that code peer review and collaborative design increase the probability that the code will be co-owned.
I would add that iterative methods where the team is self organized and aims at the same goal promotes shared ownership.
the answer is extremely simple:
so when code must be modified or refactored, if the unit tests all pass, there is no reason not to trust the results [assuming adequate coverage of course]
if a team member refuses to participate in this circle of trust, replace them - i am not kidding; prima-donnas, naysayers, and gloom-and-doom-ers can kill a team, which destroys the joy of success
In my opinion it is a combination of pair programming as well as pair swapping. The best and most optimum team that I have worked on we would pair program (and use Test Driven Development) but also swap pairs as often as possible. There are papers written on how often people should swap not to prevent progress due to too much swapping.
However, in the team I was on, we would try and swap pairs once every day or second day. And as you cycle around the pairs, you slowly gain more and more knowledge on each area of the code base and everyone contributes to everything.
Another thing that the article "Promiscuous Pairing and Beginner’s Mind" (PDF) states is that you put someone in the pair that knows the least about the particular area of the code base. Not only will they learn about that area but they will also think differently compared to someone who knows the area intimately. Therefore they will ask more questions and challenge the other pair more. I have found this technique to be very successful.
The trust part comes with time. In regards to trusting and promoting the methodology, that can sometimes be hard as people won't be used to having someone constantly questioning everything they're doing. It takes time to learn how to pair with everyone and how to make compromises. If people are constantly learning new and improved ways of developing, the people who might be afraid of others changing their code for the worse might soon realise that people are changing their code for the better in the long run as everyone gets skilled up - which is easier and faster when people are pairing and you learn by seeing others doing things - whether it be new design patterns or even a new IDE shortcut that will speed up development.
I've seen people leave teams because they didn't like it. But from my experiences, I found that I was quite skeptical at the start because: (1) i wasn't used to someone sitting next to me all the time, (2) someone questioning everything I did, (3) I felt scared to spike things out in fear of looking stupid; however (1) over time, you eventually feel weird when someone ISN'T sitting next to you and (2) you realise that if you don't know the answer, either they know it and they can tell you immediately instead of wasting time yourself or both of you don't know the answer so you both spike it out.
After the first month of feeling skeptical, I've grown to love it and you learn something new every day and go home feeling as though you've accomplished something. You never again have that feeling where you've been assigned a task and have been left in the lurch by the rest of your team to try and resolve it and therefore spend plenty of overtime trying to resolve the issue. Because you're pair swapping and pair programming, everyone's thoughts and ideas goes into the problem and the feeling over "overwhelming" pressure isn't there - in my opinion.
I would like to point out an anti-pattern for joint code ownership. Don't have the same programmer always work on the same code. This is a trap I have seen team after team fall into over the years. It is tough to assign a project to a developer that is not familiar with the code when there is another developer on the team that is. But it creates team ownership of the code, and brings some level of code review to your various modules.
Having two or more developers go through the code is one idea I have seen and liked. The idea here is that you'd have at least 2 developers, A and B, where A may initially write a module doing about half the work, and B then enhances and extends it to the initially completed version of the module.
If there are those with trust issues then one may need to have some exercises in a sense to give an idea of how this will work and if someone doesn't like it then they may just have to find another job. Another way to view this is the team member with an ego that may cause issues for the team as he or she may try to get the glory in good times, e.g. that there is my code and it is awesome they could say, and pass the buck in bad times, it isn't my code, it is perfect.