In your experience, what has inspired you to change a fundamental programming tool

Question

A lot of what I am working on is changing the mindset of a community of developers. Moving them from one tool to another, or to picking up a new tool.

What are some of the suggested or recommended ways to get a community to pick up a new meme?

While we can mandate tool usage, this is a last resort. I would rather have the developers move to any new tools of their own accord.

I'm not a programmer, I need to understand why a programmer will move from one tool to another.

Edited the title thanks to a fabulous comment! My world runs on Meme's, tipping points, and general pressures. This is why I needed to ask.

And clarifying yet more- I am the middle manager needing to plan and manage an implementation and not a sales person.

Answer 1

I think the best thing is for you to start using it, everyone else to see how easy it makes your life, and then they will follow. I think that's how memes work. One person does something, and it catches on.

Answer 2

I usually try to highlight how much easier the new tool will make their work. I'll demo whatever it is, show them handy shortcuts, etc.

You're right about mandating tools - that makes everyone angry and then they'll definitely be more stubborn about switching.

Answer 3

training - i generally find that people are reluctant to try new tools because of the steep learning curve involved.

Answer 4

by not calling it a "meme"...

if (CommonLanguage) {
  programmerUnderstand = true;
}
else {
  throw new WTFException;
}

Answer 5

Hold an info session about the tool/utility/etc in question for the developers involved. If there's an appealing capability and/or feature, usually uptake should be automatic.

A lot of resistance to change is because some developers don't have time to investigate something that may or may not improve their workflow. The last thing you want to be doing is introducing Emacs to non-Emacs users in the middle of the busy development cycle, for example.

Answer 6

Good engineers will move to a new tool as soon as they perceive the benefit to be greater than the cost. Sometimes their perceptions don't match reality and they need showing, but I wonder, if you are not a programmer, why are your perceptions more likely to be correct than theirs?

Answer 7

A meme is a unit of culture. You can't force a change like that; it's evolutionary, based on interaction. So if you want to introduce a new meme, you do exactly that: introduce it. This can be done through practice, education, publishing, and so on. Your current developers may not accept the change, but the developers following them will.

To start with, you need to understand why the developers use the tools they currently have. Then you need to have a good reason for why they should transition. Even if you introduce a tool into the culture, it won't go anywhere if there's no buy-in. You have to find the balance between what you want and what they want.

So my suggestion to you is to add a new tool to the toolbox with the intention of getting the developers used to it, letting them find a way to make it useful and understand its value. You will need to expand the understanding of the tool's value through some way that the developers will accept.

Answer 8

Since you claim not to be a programmer, what makes you think the new tool is so good?

I speak as someone who has to tolerate a really unpleasant development environment, because some managers succumbed to some convincing marketing material.

Answer 9

Consider a pair of recent tools that have exploded in popularity among the hipper set of developers: Rails and Git.

The first time many people heard of Ruby on Rails, it was in connection with this screencast of the developer making a functional blog, with comments, in 15 minutes. Most web developers outside Microsoft shops were working with straight PHP or Perl, so this was a revelation. Even though RoR did little other frameworks weren't already doing, it was better than the competition (which is always what people are actually using, not necessarily what's the best out there), and it was marketed by simply showing what it can do.

Git also has a famous video: the Linus Torvalds Tech Talk. The approach is somewhat different from the Rails video. Linus simply verbally compares Git (and distributed VC in general) to what people are using, CVS and SVN. What sells it in this case is his arrogance. He's known as an extraordinarily smart developer, so when he acts like Git is the only worthwhile VCS, you believe it.

The lessons to take from these examples are as follows:

1. Show them what the tool can do. Programmers need to see real-world benefit from any change in their toolkit or workflow.
2. Know it's the best, and act like it. Confidence inspires confidence; trite but true.

Answer 10

Why do you want these developers to change tools?

First, just tell them your reasons. If they agree, they'll change. If not, you should listen to their reasons and reconsider your own.

Assuming your developers agree that changing tools has benefits, consider asking, "What would help you pick up this new tool?". Then act on their recommendations.

Answer 11

The answer is 'Software industry is in its child stage'. So it is obvious that technologies gets changed more often so as tools I started my career with C++ and in 2000 .NET came and I changed to C# and now I am in WPF silverlight which needs more different tool.So The IDEs I changed to stick with MS platform

• Borland/Turbo C
• Visual Studio 6 + Source Safe
• VS2003 + Source Safe
• Vs2005 + Team System
• VS2008 + Team System + Expression Blend + Expression Design

But I am pretty happy with the way the tools getting matured.

Answer 12

I already wrote this in a comment.. but now I think it's worth promoting to an answer.

Find an opinion former. Someone respected in the community you're targeting, and someone vocal. If that person says 'I've started using xxx and I'm liking it', at the lunch table, on their blog, at conferences, you're halfway to winning the battle.

So target them. Give them as much help and support as they need to get started with the tool. Do this for a few key people, and soon the community will snowball.

Don't try to fake this. People can tell astroturf from grassroots support.

And make sure the tool is actually useful. Those same people can just as well blog "I tried xxx and it sucked".

Answer 13

if you're not a programmer how can you decide which tools are better?

if you have good programmers in your team to help you decide which tools are better why don't they try to convince the fellow programmers - being much more authentic sources to listen to than you, just admitting that you're not a programmer? :)

if the programmers deciding the tool and ultimately soft-forcing multiple people to use it are really up this responsibility, they should already have blogs or at least being active in the community so why don't they use their influences to make this change the grassroots way?

i think these questions should actually precede yours :)

Answer 14

A few random thoughts on the subject:

There's a fundamental difference between "A is better than B" and "people are convinced that A is better than B". Companies introduce new products all the time that are better than the competition, but nevertheless fail, because they don't have the marketing talent or the resources to promote them successfully.

Also, if you want to convince people to change from B to A, it's not enough to simply convince them that A is better. You have to convince them that A is so much better that it is worth taking the time and trouble to switch to it. Using a new development tool usually means a lot of effort learning how to use it. Yes yes, I know the advertising literature always says it's completely intuitive, or you just turn it on and it works. But in real life there are always subtleties and nuances and complexities. I've been programming in Java for over ten years now and I still regularly discover details I didn't know before.

Some people will leap on every new thing because they love novelty. Others resist every new thing because they are comfortable with what they already know or do. Both attitudes are dangerous. But if you're trying to push a new thing, the trick is often to find the novelty-seekers first and worry about the traditionalists later. If you can get a few people who will be enthusiastic about at least trying it, and it turns out to work for them, they can become allies to convince the more reluctant. If you start out trying to sell the traditionalists, all you will accomplish is meeting resistance.