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.

To start with some background, I took up a new developer position this summer and ended up being the newest member on the team, yet with most experience under the belt.

So far I have managed to push sanity initiatives through easily enough because of low adoption costs (in terms of time and effort). However things have leveled up a bit.

One of my teammates, although experienced, does not really understand SVN. Naturally, blank areas on his mental map depicting oceans of SVN cause him to adopt rather strange usage patterns.

For example, he had declared a policy of "1 SVN commit per day per developer" because otherwise "the server would soon run out of disk space". When I explained him that SVN commits are deltas, not full copies, he responded with doubt and even today I'm not entirely sure if he understands what it means.

We also had a heated argument about whether to include Eclipse .project configuration in SVN. My teammate insisted we should, although it has caused numerous pointless conflicts. I was against keeping individual developer configuration files in SVN. Finally, it turned out that my teammate had a practice of re-checkouting the entire source tree after every commit to just make sure "code committed into repository works". That was the reason he was so adamant in keeping the project configuration in SVN - so it would be easy to re-import the project. When I explained that commit synchronizes working copy to remote byte-by-byte which makes re-checkout unnecessary, my teammate responded with doubt again and eventually waved the whole issue off as insignificant.

In my opinion, our team wastes time by resolving SVN conflicts in project configuration files which contain only developer-specific settings that need not be shared to SCM at all. All this mess because someone tailored the process around incorrect assumptions.

How can I convince a teammate, who sees oneself as senior, to get a better understanding of SVN basics?

share|improve this question
5  
Have you read Driving Technical Change? It's a Pragmatic Programmers book that might be relevant. It presents patterns of people who oppose changes and techniques for overcoming these particular groups of people. I'm still reading it, and I don't have it next to me now, so I can't quote it, but it sounds relevant to your problem. –  Thomas Owens Oct 11 '11 at 12:12
3  
Introduce him to git. "Hey look at the next generation of SCM". After learning git concepts he'll have no trouble understanding SVN. This may sound less offensive since he (likely) doesn't already use git. –  kizzx2 Oct 11 '11 at 16:45
1  
@CourageousAnonymousCoward, it's always disappointing when people who exert control over the same thing disagree. This is exactly the situation when a leader (who has more power to exert more control) must intervene. Problem is, it's tough for the people involved to ask for help. For the sake of the team, someone should ask. –  GuyR Oct 22 '11 at 13:12

16 Answers 16

IMO it is best to separate those issues which cause direct problems/harm to the project from those which affect only that single developer. E.g. if he prefers to checkout everything multiple times a day, it will slow him down, but otherwise won't affect others. So you can just let him do that (until there is a noticeable performance lag in his work), and save yourself from the trouble of arguing over it.

Other issues you mention, like keeping Eclipse .project files in the repo, or 1 commit per day, are where you should focus, to allow the team to progress as smoothly as possible. First of all, you should ask/collect feedback from the other team members, whether this causes problems for them too. If there are others, together you can exert more pressure, and if needed, you can easier escalate an issue towards management.

Regarding the "SVN runs out of disk space", it would be easy to refute his belief by doing an experiment (potentially in a separate test repo). You just need to monitor the size of the physical repo file hierarchy before and after committing changes into one huge text file, or even lots of files. If that doesn't convince him, nothing can.

In that case, unfortunately you probably have an authority issue, where the other guy sees accepting advice from someone "lower in the rank" as a loss of his dignity. Such conflicts can't be resolved by logical argument. You need to escalate it towards management, but be careful to ensure you have enough support (from teammates and/or management) before you do so. Such a move may be perceived by the other guy as an open attack, thus can have problematic consequences (to either of you, and/or the peace of the whole team). So think thrice, and discuss with your supportive colleagues before you make that move.

share|improve this answer
2  
My impression is that my teammate simply wants to carry on as he has done so far and he isn't really interested in rational discussion or facts. However I'd like to use positive motivation, like somehow spark his interest in using SVN properly. Any advice on that? –  Courageous Anonymous Coward Oct 11 '11 at 9:49
5  
@Anonymous, sparking someone else's interest to learn new stuff is usually close to impossible. IMO the best thing you can strive towards is get the rest of the team to embrace the new way, remove/neutralize obstacles caused by this guy, and let peer pressure work... if that has any effect on him, he will eventually catch up with the others (the latest when the others start making jokes about his olden ways ;-) –  Péter Török Oct 11 '11 at 9:55
4  
@maple_shaft - Er.. I think You are mistaking me for someone from Your past. The issue here is that he, I and the whole team wastes time by resolving SVN conflicts in project configuration files which contain only developer-specific settings that need not be shared at all. –  Courageous Anonymous Coward Oct 11 '11 at 11:12
3  
@AnonymousCoward svn ignore is always an option. –  Christian P Oct 11 '11 at 11:28
3  
@maple_shaft - For the same reason one member of Your old team was allowed to use Emacs. Creative freedom is good a thing. –  Courageous Anonymous Coward Oct 11 '11 at 12:05

Point him to some learning material about how SVN works and what are the best practices when using SVN.

As @Peter says - choose your battles carefully and don't waste your energy on fighting with someone that obviously don't understand the basics. SVN isn't exactly bleeding edge technology and it's been here for a while so there's enough information about it.

share|improve this answer

Just talk to them. Look, I'm a senior developer, but there are things I don't know. That's the nature of the business. If they become defensive or aggressive that's a personality issue with the developer in case and that should be dealt with by the team leader, or if they are the team leader, by their boss.

share|improve this answer
1  
@AnonymousCoward, if you cannot answer his question satisfactorily, he has a point. –  user1249 Oct 11 '11 at 10:47
3  
Saying you shouldn't use a better way because you've never had need of it is IMO the worst excuse a programmer can give. If that was the case we would all still be writing Assembly or C because "Why should we do it differently?" That's an excuse, not a valid point. The obvious answer is because the way they've done it for 5 years is obviously inefficient, ineffective, and contrary to professionally-accepted ways of doing things. –  Wayne M Oct 12 '11 at 2:30

If your company uses wiki, write some high quality posts about SVN:

  • Why should you use it?
  • When should you use it?
  • What problems does it solve?

etc.

It will catch CTO's eye, and everyone who refuse to use will have to use :)

share|improve this answer

There's a lot of superstition around source control. It's counter-intuitive, the math is arcane, and it involves the single most important asset a software company owns. I have to admit there's a part of me that still doesn't trust it. But I wouldn't do without it for a minute.

One solution might be to offer to take over responsibility for taking care of the repo. Of course, if you present it as "it's a lot of work for you, and this just happens to be an area where I have some experience", rather than "you don't know what you're doing" that'll have a better chance of working.

If "sees himself as senior" means what I think it does, he won't let go of it because he sees it as a source of authority and control. So workaround for you might be to use Git locally to manage sane commit units and branches, then just push to svn once a day like he requests. Git is designed as a peer-to-peer system and to have a full repo copy on each local machine. You could offer git to other developers who would prefer doing it that way, and it can remain just a supplement to SVN that individual working groups (whether one or more developers, formal or ad-hoc) use internally. And when the day comes that senior guy relents, moves on to another department or company, or paints himself into an unrecoverable corner with his SVN policies, you have a head-start on cleaning it all up.

share|improve this answer

Try keeping a log of the 'SVN time wasting'. Every time there is a conflict/checkout/version issue that needs resolving, make a note of how long it took you/the team to resolve it. If it turns out you're wasting a considerable amount of time every week, escalate it with him and the management. I'm sure management will soon ask for solutions if they realize productivity can be improved by simple changes in the work process.

Or try to convince your colleague to have a trial week where the team uses your system of checkins (if that's easily achievable with your current projects and codebase). Promise him that if it doesn't work out you can switch back to the old system after the week is over. But he might come round after trying it out himself.

share|improve this answer

Start a brown bag initiative, once very few weeks someone holds a lunchtime talk about something they know about and presents it to the others.

You use this as excuse to present SVN in detail and maybe some of the thinking behind some of the alternatives.

A few weeks later someone else can have a go.

share|improve this answer

Get the guy fired and be done with his heel dragging and obvious taint towards newer technology. Or really blow his mind and start using GIT. If he can't understand SVn then he surely will be blown away by GIT.

share|improve this answer

You seem to be fighting a losing battle but you can pull through. Machiavelli in The Prince described how difficult it is for one to change the status quo. I would suggest reading that chapter again and then maybe not doing what he suggests -- it can be harsh.

You should bring your concerns to the senior developer in private and make sure you criticise constructively the way things are done and not him or any other developers. Then offer to do a talk and write a best practice guide. Show them how understanding SVN better will make their lives easier. Ultimately, it's all about costs and efficiency. If you can prove that your way improve things without stepping on toes then you may win this one.

Try to understand why the senior guy(s) is(are) using the repository as it is. What are their concerns? What are they trying to achieve? How can you help them be more productive? Above all, do try to keep a calm and professional approach. It is easy to get frustrated. Be assertive: Assertiveness at Work: A Practical Guide to Handling Awkward Situations by Ken Back and Kate Back is a good read. Finally, think "how would I convince myself to switch?". Be an honest devil advocate and that may help you come up with good answers and questions to ask.

As a side note, I would be careful to use humour. It may work wonders or it may make you sound like an asshat. Thus, I would avoid it.

Fundamentally, do pick your battles carefully as you may not win this one. If that is the case, either do not care any more or look for a different job. Harsh, I know.

share|improve this answer

I will try to give you some hints backed by my personal experience.

One of my teammates, although experienced, does not really understand SVN. Naturally, blank areas on his mental map depicting oceans of SVN cause him to adopt rather strange usage patterns.

For example, he had declared a policy of "1 SVN commit per day per developer" because otherwise "the server would soon run out of disk space". When I explained him that SVN commits are deltas, not full copies, he responded with doubt and even today I'm not entirely sure if he understands what it means.

Even if disk space were an issue, you could always commit a lot of files at once, so I think what he suggests is the wrong solution. Furthermore, it is possible to waste a lot of space by checking in large binary files because SVN does not store deltas for binary files. One check-in per day is also bad because it forces you to commit changes that do not belong together, e.g. in case you fix more than one bug per day.

The solution we have adopted in our company is that there is a filter rejecting any commit containing binary files. We can force the commit by using a special keyword in the check-in comment (we have to show SVN that we know what we are doing). Once in a year or two a project manager archives old branches and removes them from the repository. With this strategy we do not have space problems that I know of (our repository supports several different projects and has over 100000 revisions).

Summarizing, you could tell him that you agree with him that disk space is an important issue but, on the other hand, point out

  1. the importance of feature-related check-ins instead of one monolithic daily check in;
  2. the fact that by checking in one large binary file per day, one could fill the disk anyway.

Then you could suggest that you have a meeting (possibly with other developers or system administrators as well) to discuss strategies for keeping disk space usage under control (e.g. binary-file filters, regular backup and clean up of old unused branches).

We also had a heated argument about whether to include Eclipse .project configuration in SVN. My teammate insisted we should, although it has caused numerous pointless conflicts. I was against keeping individual developer configuration files in SVN. Finally, it turned out that my teammate had a practice of re-checkouting the entire source tree after every commit to just make sure "code committed into repository works". That was the reason he was so adamant in keeping the project configuration in SVN - so it would be easy to re-import the project. When I explained that commit synchronizes working copy to remote byte-by-byte which makes re-checkout unnecessary, my teammate responded with doubt again and eventually waved the whole issue off as insignificant.

In my opinion, our team wastes time by resolving SVN conflicts in project configuration files which contain only developer-specific settings that need not be shared to SCM at all. All this mess because someone tailored the process around incorrect assumptions.

Do you use a build server? We have a build server that checks out the complete project and compiles it every night. The next morning the testers have a ready-to-test installer of the product (if the master build ran correctly) and we (the developers) have a build report with all the warnings (and errors, in case there are any). Of course, you need to set up standard configuration files for the build server and check them in. Each developer can then check them out along with the rest of the project, but they are not allowed to check in any local changes.

In this scenario you address his need to be able to check out the complete project and build it at any time. You also avoid spending time to merge changes that should not have been checked in the first place because they are not part of the product: the product is the master build, and that must be kept clean. If someone breaks the master build (e.g. checking in his own .project file) you can revert the changes or force that developer to fix the problem.

Maybe if he brings up the issue again, you can again suggest to have a meeting (possibly with other developers) and find a common strategy together.

How can I convince a teammate, who sees oneself as senior, to get a better understanding of SVN basics?

I think the best strategy would be to avoid bringing the conflict to a personal level and rather discussing the issues at hand and possible solutions. If you have the impression that he is looking for a personal confrontation, here are some suggestions (again, from personal experience):

  • How is your team dynamics? Are your other colleagues having a similar experience with this team mate? There are a lot of small, not too explicit hints that a team can give to one of its members to discourage certain behaviours (small jokes or observations) and encourage constructive confrontation (proposing a meeting, or bringing up a topic informally during a coffee break). Sometimes a good team can quickly isolate a disturbing element and bring things back to normal.
  • How good is your personnel management? We had one conflict case in our company and the head of personnel had to intervene to clear the situation. It was not nice, but sometimes the working atmosphere deteriorates so much that it will not get better by itself. I hope this is not your case (I do not have the impression it has gotten that far yet) but it is always good to know if you have a good personnel administration or if you have to solve conflicts on your own.

Why am I writing this? You say that you want to "convince a teammate, who sees oneself as senior, to get a better understanding of SVN basics". To me it sounds like the conflict might be getting too personal. Some psychologists maintain that 70% of our communication is at the emotional level, if this level is not working, then people stop speaking about facts because they are too busy dealing with emotions.

So, besides explaining your points, you could also try doing something to improve the communication. Inviting for a coffee or to have a lunch break together, having a short conversation about a topic that is not related to work, etc, can improve the communication and bring your colleague's attention back to the important facts that you want him to understand. If he accepts this kind of communication, then maybe the conflicts that you had so far were related to the fact that you do not know each other well and there were some small misunderstandings but he is probably open to build a constructive collaboration. If he refuses, then there might be a deeper hostility on his side.

In this case, I think you should wait until your roles become clearer. If you team mate does not officially have a higher rank than yours he has no point getting irritated at your attempts to improve things. With time he will have to accept it or make a fool out of himself if he keeps trying to show he knows better. If he does have a higher rank, you should find a way to let him understand that this is not under discussion: your observations are aimed at improving the productivity and not at undermining his position, this must be 100% clear. When the roles have been clarified, if he still cannot accept constructive suggestions or criticism, then he really must have some problem with self-esteem or something like that.

So if all the strategies above fail and you keep feeling (very) frustrated, I am afraid the only reasonable thing to do will be to pack your things and look for a better place. I made this experience three years ago and found a much better company in which I am very satisfied now. Maybe this is not your case (I hope not of course) but try to understand this point too.

Just my 2 cents.

share|improve this answer

1. Let Subversion solve the problem for you. The way you tell it, your coworker is relatively unsophisticated when it comes to Subversion. In that case, a technical solution could be a good option. If the rest of the team agrees and you can get your manager's blessing, add a global-ignores field to the repository config file so that you can exclude the .project files and others that you don't want under version control.

2. Help him out. Instead of imposing your way of doing things on him, try to help the guy do things his way without causing problems for everyone else. If your coworker is working in his own branch, you really shouldn't care what he commits. If he wants to commit his .project file so that he can checkout a fresh copy of the whole directory, that's no problem for you. The only thing you should care about is that he doesn't merge his .project file back to the common development branch. That should be easy to manage, again, by setting the ignore property on the development branch to exclude the .project file.

3. Seek support from above. Don't get into a "you're not the boss of me" argument with the guy, but if his behavior is causing a problem for you then make sure that your manager is aware of the situation. If you're not sure how to approach your manager, try asking for advice: "Mike, I've been trying to talk to Larry, but I'm just not getting through. He insists on X, Y, and Z, and the rest of us spend a lot of unnecessary time working around the problems that creates. Can you give me any pointers on how to deal with the guy?"

4. Ignore him. Why does anyone on the team listen to this guy? Does he have any actual authority over the project? Who cares if he declares a one-commit-per-developer policy if he doesn't have the power to enforce it? Let him think he's Yertle the Turtle if it makes him feel better, just don't let him create real problems for you.

share|improve this answer

I was once in the reverse of your position about 8 years ago when SVN was reasonably newish technology. I was a senior developer and was requested/bugged to install SVN by a junior dev (actually he was more accurately IT support than a dev). I took an open mind despite my initial suspicions regarding increased workload, needless complexity, etc ... and then became a huge fan of it.

In my view, from what you have described this problem definitely comes down to team personalities - his stubbornness is proving a hinderance to the team as a whole on this issue. You may be better off just backing off at this point and letting pressure from the rest of the team build naturally to force his hand.

share|improve this answer

This is pretty much a case of "lack of authority" and a person who applies the power of his own fear to keep things "under control"

To resolve this find someone that has inspired your teammate or someone who he respects and that is able to explain the urgence of using something like SVN. That way his fear for change and basically "losing authority" is not in play beacause it is not a team member telling him what to do. I would refrain from using someone like a manager to speak to this guy because that only adds pressure and might even create a more stressful situation for yourself.

share|improve this answer

As a leader, manager and team member, I have had to deal with resolving professional and personality conflicts on many levels. No matter what role I am hired into, I typically get accepted as the leader even when I do not want the role. The reason for this is the way I deal with these conflicts.

Unlike many of the people here, I do not agree that dealing with this situation is a "give up" or "show him a new tool" or "wait for him to fall on his butt or disapper". Most importantly, it is never a good idea to wait until roles are more firmly defined. Those roles get defined by people who do not wait, by their convictions, ethics and ability to deal with critical situations whether they involve people or not.

There are several methods to dealing with the type of person you are describing in these situations. The first and foremost step is to investigate why he is behaving the way that he is. It has little to do with what he knows or doesn't know. He could easily have found out this information previously, so the question really is one of two things: "Why didn't he?" or "Why is he rejecting the information he is being provided?" This will aid you into finding what exactly needs to be addressed.

In my experience, programmers (including myself) refuse good practices or new tools for just a few reasons:

  • The source is not credible. In an industry that becomes more and more polarized each day between the "cult of Mac" and the "MS worshippers"; between "Open Source Ideology" and "Proprietary Practicality"... etc etc -- There are many who always have doubts about the information provided and its potential of corruption due to the bias of the submitter or the writer, even when that information is verified as credible.
  • Prolonged Bad Experiences... with a similar or even the same technology or practice. Nothing is perfect when it starts, and many start out with less than 1/4 of the features than they end up with. It is entirely possible that he had many hours or days or even weeks working with either an inferior product or the same one during a poorly implemented phase.
  • A "Credible" Source... conflicts with the information he is being presented. By "credible", I mean some person or entity that he trusts. Many people tend to elevate the people that we trust to levels that do not represent reality. This source does not even have to have imposed this belief upon the person. Most often, we do it ourselves. It often gives us something or someone to aspire to be like, in at least one aspect.
  • Lack of security This was highlighted by a previous poster. Our programs become assets from the second we start working on them. Not just to the companies we work for, but for the people we work with. This is not simply a control issue. Some of us want to be able to show our neat stuff to the people we care about. Some of us want to make sure that it isn't harmed by an outside person or product. For some, it is an extension of how we think and feel, even. It houses some of our philosophies and ideologies and exposes our intellectual cores. For many, it is our future, whether it is for a class, an employer, or client. For some it is all of those. "Security" in this sense does not apply to the data, necessarily, or the code. It really applies to our sense of safety in protecting whichever of these is most important to us.

Finding out which is the factor is frequently quite easy. Get the person into a neutral setting. Explain to the person what you are observing, in general. Ask the person honestly what is causing this behavior. Now, it doesn't always go well, but most adults respond pretty well when you seem to want to help someone who seems to be acting irrationally. Chances are he is not acting irrationally, but isn't aware that nobody can understand what is really going on.

Once you find out what the issue actually is, you can equip yourself with the proper tools to deal with it. If it is scenario #1, encourage him to do the research from the sources he trusts and (this is important) get back to you with his own findings. This will tell him that his own information holds value with you. In the case of scenario #2, provide accurate comparisons to what is different now than before. Encourage him to give it a try, but have a back-up plan for if it goes awry. For scenario #3, tell him to requery his source with YOUR information. Chances are his source does not hold the views that he thinks he does, but did at one time. Most of us adapt over time, so his viewpoint has probably changed. If he is not willing, encourage him to introduce you to his source. And finally, for scenario #4, assure him that his worries are your own. (They should be on some level) Demonstrate how this "new" tool can protect his interests and increase his security. And if it can't, provide some additional alternatives to help his sense of security while taking advantage of the benefits of a repository.

I know all of this sounds too simple to work, but sometimes it simply does. In fact, the more sincere you are, the more often it does. By addressing his needs, you are addressing the needs of the team, whether he is a "senior" or not, because he is a part of the team. Showing him that you want to be on the same page as him, but simply are not, might encourage him to begin to work together with you. If you have done all of this, and still reach no resolution, then you have done all you can short of speaking with the team leader.

FuzzicalLogic

share|improve this answer

I recently read Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should, which is published by The Pragmatic Programmers. This book provides background that you should know before trying to introduce technical change, a number of patterns in people who oppose or refuse to change, techniques for implementing the changes, and then strategies for maximizing the use of these techniques and all of the people around you.

Based on your post, I'd say that your teammate probably falls into the Uninformed or the Cynic pattern, but he might also be a case of the Irrational. Some of the techniques recommended to counter these types of people are to gain experience within the target environment so you can find any issues and present answers to problems that other people will run into before they happen, solve the right problem, deliver the message passionately but without being over zealous, demonstrate the techniques by clearly showing the advantages of your methods and tools and sell them organically (but don't create problems just to solve them), and get publicity and buy in from the rest of your team. However, if he's Irrational, there's not much you can do but be prepared to counter their irrationality and not let other people fall victim to their persuasion.

Finally, then you begin to use these techniques, you need an overall strategy. It's important to not let those who are actively hostile or irrational slow you down - ignore them. Instead, find people who you can demonstrate and convince that you have a better way and apply the appropriate techniques based on them as an individual. Once more people see the improvements your knowledge offers, use them to continue to convince others. Finally, use this grassroots effort to convince management that there is a better way, but be sure to put it in terms that they can understand (time, money, quality).

share|improve this answer

Don't try to "convince" this guy of anything. People (even programmers) are not going to respond to or respect reasonable/logical arguments from someone they see as junior to them. So don't waste your breath. Instead, work on building a level of trust with this person. This person will listen to what you have to say only when he is open to it.

In the meantime, you have real problems:

  1. The guy checks his .project file into the repo: just ignore it. you don't have to modify the file, neither does anyone else on the team who knows better. Let it go. If it gives your "senior member" a warm, happy feeling like a security blanket then so be it.
  2. There is a perceived budget on disk space: This is the reason Mr. Senior dictates 1 commit a day. Is the shortage on space real or perceived? Even if it is just perceived, maybe there's something you can do to change that perception. That should be dealt with immediately - if you take the initiative it also helps to build trust.

I might also add that this guy will be willing to adopt better SVN practices when he thinks they were his ideas. That will take some forethought on your part, and he will likely take the credit for establishing better practices - but you are OK with that.

share|improve this answer

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.