How to tell someone that their programming methodologies are obsolete?

Question

I'm certain that I'm not the first person to run into this scenario, so I figured I'd throw it out there and see what the SO hive has to say. As a disclaimer, the person on which I base this question is not someone I currently work with.

What is a tactful but effective way of showing someone that some of their "old dog" habits have fallen out of favor or have been replaced with more effective or manageable solutions? The dynamic nature of development tends to support a LOT of backward compatibility when it comes to methodologies, so an "it doesn't work anymore" is rarely an honest option, but often these old habits have been superseded. For example..

• Always write wrappers for framework methods, since they'll change and break your code. Never call anything in the framework directly
• Don't use properties, because anything that could execute code should be in a method/function. That's what they're for.
• Never use third-party libraries, since they'll break

The list goes on, and I'm sure that people here have an impression of what I'm getting at. A lot of these aren't even methodologies, per se, as much as they are kneejerk reactions to the prospect of change.

How do you (and, by extension, how do I) deal with scenarios like this and maintain a good working relationship with these people?

EDIT:

I've gotten a couple of comments on the nature of the examples. These examples are designed to show the unyielding mindset, rather than illustrate a fault with any particular habit.

Answer 1

I find it really depends on the personality of the person in question. For example, if he/she is open to new ideas, but simply hasn't been shown the possibilties, perhaps a diplomatic conversation will do the trick, stating the ways in which it will help to change. Basically, always stressing the positive.

However, if the person is one of these "i only like it this way", and not open to change it is much more difficult. In those cases, I usually ask myself, "am I wanting change, just for change sake, or is there a good reason for this?" If I have a good reason, I recruit others and suggest the change in a group setting.

If they still hold out, and I have several others backing me, and I KNOW it is a necessary change, then I'll raise it to my boss for more direct action.

Answer 2

Show them a better way, explaining why you think it is better.

Unless you're in a position to mandate a methodology, or can get management buy-in, trying to force someone will just leave you frustrated and them resentful. You just have to accept that and move on.

You could also phrase that as pick your battles :)

Answer 3

People that do not change their habits are the worst possible programmers...runaway from them as fast as you can

Answer 4

The Pragmatic Programmer mentions that it is also worth timing your request wisely. The classic example is waiting until a crisis happens before proposing the solution, e.g. suggesting source control after someone accidentally deletes all the code. Prevention may be cheaper than cure but cure is much easier to justify.

Answer 5

Leave them be. If you're not comfortable approaching them with new ways to do things then their own antiquated style will eventually catch up with them and you won't have to work with them any longer anyway.

Answer 6

Assuming you have the proper authority, you can try creating and enforcing a "Best Practices List" containing some items specifically targeted at their habits - under the guise of code uniformity for the team, of course, not that their way of doing stuff is bad ;)

Answer 7

Unless the code they're writing is complete junk and causing real problems, leave them alone and perhaps pursue a less aggressive approach. Maybe strike up a conversation about one of your favorite new development techniques and how it saves you a ton of time when working on a project. Any kind of direct approach is going to cause resentment, no matter how much you butter them up first.

You might also consider that their methodologies have some merit, that those methodologies work for them and, in then end, they get the job done. There's never a silver bullet.

Answer 8

In the past, I've dealt with this by presenting new information to them and then trying to get them to think it was their idea to make the change in the first place. Usually, when they think they came up with the idea, they are much more likely to use it. :) It's a little manipulative, but it is better then open conflict and it avoids making them feel out-of-touch. It also gets them to think about their current practices in a non-accusatory manner.

This works well if you are younger then the person in question (usually the case). Present them with book/webpage/etc on the topic with the information; say you are not quite sure you understand it and are looking for help from someone as experienced as they are to see what this is all about. Explain the concepts as you understand them; ask them something simple about it that they should be able to answer. Try to steer the conversation toward practical applications; ask them things like "So do you think an example of this would be something like....". Often, they will get the idea of "Oh, we could use that here!" and then will change themselves.

People seem much more open to change if you let them believe they originated the change themselves. :)

Answer 9

I'd agree with the answer that says "leave them be" with the exception of two scenarios.

1. their low level of productivity is dragging down the team, or
2. their way of working is not compatible with the way in which the team is working.

For the second scenario, I'm thinking of situations like when they are insisting on BDUF when the team and customer is working on an agile basis, e.g. Scrum.

Some things are just chalk and cheese and will never go together.

As an aside though, I'd be inclined to find out why they haven't changed from their "old" methodologies. Maybe they know something about the problem at hand that you don't.

Remember, just because it's new doesn't instantly make it better! Pass their lessons learnt, experience, even wisdom through your filter and don't just dismiss it outright,

HTH

cheers,

Answer 10

I've been coding since the late 70's. What you describe is not some old methodolgies which we used to use back in the day. It is hyper-defensive programming. I'd almost worry that your developer was beaten as a child. :-)

OTOH, a certian amount of that can be sensible. For example, if you are using a library that isn't OpenSource, it is pretty much a guarantee that your vendor will go out of business or otherwise stop supporting it one day. Unless you are writing throwaway code, doing a certian amount of planning for having to replace it ahead of time is simply being responsible.

Answer 11

Conduct formal Code Inspections following the approach that Steve McConnell outlines in Code Complete. This will do two things, 1- it will apply positive peer pressure on the developer in question to adopt the standards of the entire team and 2- will force the team to document the standard approach for dealing with the examples scenarios you list. At a minimum this documentation can be in the form of an Inspection Checklist.

Answer 12

I have taken the habit to listen to these people because it happens that they are not always or not completely wrong.

This is especially true when working on Unix systems, which are 40 years old this year (according to Wikipedia), and are more and more popular with Linux or OS X (even iPhone runs Unix).

Answer 13

I'd definitely open a dialogue with the individual. My experience has been that people learn a good number of their coding methodologies because "that's just the way it's done." You may take something away from the conversation.

Answer 14

I don't condone using a language in a manner that isn't suited for it; being able to write code in a given language isn't the same thing as being able to write code in the style of that language--when your style doesn't match the language then it's a good indicator that you are making things much more difficult than need be.

....BUT... there is a certain amount of validity to maintaining "backwards" ways when dealing with a mature application which is built in a backwards manner. Consistency provides maintainability and readability, if a team works on a project and everybody injects their own style or approach then the project becomes a maintenance nightmare.

You have to carefully balance the cost of adding a new coding style to an existing project, however if you are starting a new project then you have a clean slate to implement changes. Enforcing coding standards is a good start, but you have to be able to get a mediator (aka manager) to sign-off on the requirement before you can demand it of your peers.

Answer 15

I did not read all of the answers but...

My two cents...

There are a lot of it depends to answer this question.

1. Are you older then this person?
2. Are you respected by this person?
3. Are they ready to hear what you have to say?

You can tell someone they are a drunk but if they don't want to admit it you can not help them. They have to have the "WANT TO" to change. You have to be the right person. Remember the older you get the harder it is for MOST (not all) to change. Some are just uncomfortible changing their old habits or they are afraid to learn new ones. They will not tell you this. So until you are a asked or are respected by your peers I would tend to say nothing and continue fixing it they way you should.

During a code review if a new person to the job started pointing out bad things in the code before understanding where everyone in the group is at they had better be 100% on the money and be able to back it up or they will get looked down on by the team. When you are new to a team or just out of college do not say anything keep your head down and your eyes and ears open until you learn enough to know when to say something. Even safer wait until you have some grey in your hair and 10+ years of experience. They MIGHT listen then.

Hope this makes sense. Nathan