I run a team of software engineers where I try to instill the practice of collective code ownership. One team member is continuously threatened by an individual he feels is meddling in 'his code'. Both people contribute greatly to the team, but the threatened individual seems to be taking things more and more personally.

How might I defuse the situation and help the threatened person move past his feelings?

  • 2
    Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need. Mar 23, 2013 at 9:25
  • 3
    Please don't downvote questions that are not obviously poor without explaining why.
    – Tom W
    Mar 23, 2013 at 12:51
  • 1
    I guess a question saying, I would like suggestions when the FAQ says under close reasons, ...this question will likely solicit debate, arguments, **polling**, or extended discussion. seems like a question which doesn't match the format of this site.
    – enderland
    Mar 23, 2013 at 13:15
  • What have you done to verify that what the "meddler" is doing is actually necessary?
    – Blrfl
    Mar 23, 2013 at 14:12
  • The changes were necessary to resolve a bug.
    – ntsh
    Mar 23, 2013 at 15:20

3 Answers 3


In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.

If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.

If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.

  • There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
    – ntsh
    Mar 23, 2013 at 15:54

Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.

Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.

Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts

  • 3
    I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true. Mar 24, 2013 at 12:55

Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?

Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.

  • 3
    There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening. Mar 23, 2013 at 23:11
  • The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code. Mar 24, 2013 at 0:15
  • 1
    @MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO. Mar 24, 2013 at 5:39
  • Plus, it IS possible to set ground rules for code reviews and hold people to it. Mar 24, 2013 at 12:50
  • @AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :) Mar 24, 2013 at 19:33

Not the answer you're looking for? Browse other questions tagged .