views:

234

answers:

9

Obviously, it's easier to do with some developers, but I'm sure many of us are on teams that prefer the status quo.

You know the type. You see some benefit in a piece of new technology and they prefer the tried and true methods.

Try, for example, DBA/C# programmer the advantages of using LinQ ( not necessarily LinQ to SQL, just LinQ in general ).

For example, When a project requirement is to be cross-platform... instead of thinking about how one can run Windows on a Mac through a VM Machine, introducing the idea of using relatively new Silverlight or creating it in Java ( as an option to look into ).

I know most people don't like to be out of their comfort level, so it takes a bit of convincing, and not ALL new technology makes business sense... but how have you convinced your team to look at a new technology?

What technologies have you successfully introduced to your workplace?

What technologies do you think are hardest to introduce? ( I'm thinking paradigm-shifting ones, like MVC from WebForms... or new languages )

What strategies do you employ to make these new technologies appealing?

+5  A: 

When it comes to coding practices my favorite is to quite simply use examples. I will take a few hours and edit our code base to use the new technique in place of the previous pattern. Then send a shelveset or changelist around to the rest of the developer list displaying the difference. Or just have a meeting to talk about the difference.

Showing examples in real production code really helps other developers see the advantages.

JaredPar
+2  A: 

It's best to lead by example. Complete a successful project using the new tool and wait for developers to ask how you did it.

Chris McCall
+1  A: 

Show them how it solves a common problem. Pick out some problem that appears regularly for them and show them the solution. That will usually at least get them thinking about it.

Stephan
+4  A: 

I've successfully introduced LINQ to my company and it has helped quite a bit.

What worked for me? Show and tell. Our previous technology was database programming with C, which is quite the mess. Our lead developer did about 3000 lines of code to fill a dataset, and I did it in a 10th of that with LINQ/C#.

Once I broke down what I did and he saw how powerful it was, he was convinced it was time to upgrade.

jsmith
300 lines to fill a dataset?
dotjoe
Give or take, pretty relative really.. Was more trying to prove a point which most of us know. Database queries are a lot easier with LINQ.
jsmith
+1  A: 

Stand the two technologies next to one another, its safe to assume that advancements have been made and that what you are bringing to the table is better suited to the job at hand.

Put the raw results in front of them and let them decide for them selves!

I work for a data beauro, and until recently the company was hooked on MS Access, which was cumbersom and unfit for the job, after some serious convincing and showing the power of SQL in comparison to Access, its now the weapon of choice.

And it took standing the two techs side by side and allowing the guys up top to see for themselves, the time saved did make business sense!

Yoda
+11  A: 
  • Know the technology well before pitching it. You're going to get questions like "but how can we make it do X?", and you want to be able to give at least a general answer.

  • Try not to be a religious zealot. Acknowledging that the new technology is not perfect, that it's just another tool in the toolbox, goes a long way towards credibility.

  • Give a well-prepared live demo to show what it can do. For example, a friend of mine built a simple blog in Ruby on Rails in half an hour, in front of a live audience. I want to stress the word "well-prepared"; if things keep breaking along the way, or you don't fully understand what you're doing, or you are unable to answer basic questions, you'll hurt your cause rather than help it.

Thomas
+1 For including point 2
David Relihan
I totally agree on point 2. Come to think of it... as a sidepoint, I think it's one of the major problems people have when dealing with OS X vs. Windows. Zealots are annoying... and no one wants to be identified as one.
Atømix
OS X vs. Windows debates are stupid. Linux is vastly superior to both of them ;)
Thomas
So many good answers, but the "don't be a zealot" comment and the "be well-prepared" while demoing struck a chord with me. ( And I almost expected the Linux comment... classic :-) )
Atømix
+1  A: 

You'll need to show why it's a BETTER technology (or at least better at something) than the current tool/method in use, and probably significantly so. Otherwise, why go through the effort of learning something new?

Otherwise, convince the boss and then get a mandate ... (though I don't really recommend that if you can't get at least half the team on board).

GreenMatt
+2  A: 

I managed to convince the team Im part of to switch from CVS to Mercurial. Can you believe we were still using CVS? Neither could I when I started.

I became almost somewhat of a preacher, a royal pain in the butt. Everytime CVS screw up or caused some sort of discomfort (being brutally slow, for example) I held a little speech of how much better it could be.

Soon enough they accepted the possibility that there were alternatives (none of them actually knew there were alternatives to CVS!) and began to say things like "if there indeed are alternatives, anything must be better than this".

Thats when I made my move and simply ran some scripts converting the CVS repository into a Mercurial one and uploaded it to the company server. Once they saw it in action, they were sold.

Not that I planned anything during this little migration black ops, but in retrospect I would give the following advice to anyone attempting something similar:

  • Let people know there are (better) alternatives, it is entirely possible to work outside your comfort zone.
  • Lead by example, if you want something done, do it yourself. Show the alternative in action. No one is going to make the jump unless you jump first, especially not if they are already hesitating.
mizipzor
You don't know the pain I have... still stuck on SourceSafe
Atømix
In that case feel free to see this as a guide to improvement. ;)
mizipzor
+3  A: 

The advice from people who convinced the management to consider using F# goes something like this:

Implement the most important bits of the next key project of the company in F# in your free time and then show others what benefits it has, how quickly you were able to implement it and how easy it is to adapt the solution to changing requirements.

I think this is quite effective way - when people actually see the productivity (of any new technology), it is much easier to convince them that it is worht learning it.

Tomas Petricek
+1 I was writing about the same in other words. That is quite effective, indeed! =)
Will Marcouiller