Selling LINQ To Management

Question

I recently started working at a new company that currently doesn't use linq, but does use C# and the .net framework. I'm coming from a LINQ background, so I'm biased, but I still think there are a lot of advantages to using linq.

That being said, it's still going to be hard to influence change as I'm still very new. What suggestions do you have to sell this to management? The database systems are still relatively new, so I think now, as things are still developing, would be the best time to try convincing people to use this. This is both a technical and political question. Any help would be appreciated.

Answer 1

Articles

If you want to convince management you need outside sources. Try to find some articles that shows how LINQ improves productivity. This will help your case and help management feel more confident in the decision to move forward with LINQ.

They're not going to pick up a new technology simply because one of the "new hires" has suggested it. However, if there are solid, reliable resources that are talking about how this new technology will improve productivity, then they'll be much more likely to consider it.

Here are a couple of articles that I found (for a couple of bad examples):

• a bad example
• another bad example
• a decent example

Sample Code

Another idea would be to write some simple code with LINQ in order for them to see how it would be used compared to their current technology. Essentially do a "sample conversion" for them to examine.

Answer 2

To sell to managment you need to focus on cost savings. LINQ to SQL (im assuming you meant that) is much faster to write so can reduce project costs.

Answer 3

If you want to persuade somebody of using LINQ you might use the following reasons:

1. LINQ is just a framework feature, it does not require any modification of your runtime. This means that there is no danger for existing .Net application as long as those are written against .Net 2.0 CLR.
2. LINQ is implemented through extension methods, so you just need to deploy the libraries containing these methods to your project to enable LINQ support -- easy deployment, no need of re-compiling the libraries that are not affected.
3. LINQ is universal and in some respect source-independent. This means that you can reach higher code reuse in your project.
4. LINQ allows you to easily parallelize your application using PLINQ just by adding .AsParallel() to you IEnumerable -- there is no need to write sophisticated code for syncronisation (this requires .Net 4.0, however).

Answer 4

It also would help your case if you had additional backing from coworkers, so try to see if anyone else would like to use Linq as well. Creating some realistic sample benchmarks (using actual non-cherry picked data) would be a good idea as well.

Sometimes organizations do things for one reason or another because of the dreaded "we've always done it this way" line of reasoning and not because labor or management really feel it's the best way to do things. Getting a discussion going in your team is a good way to make changes away from that line of thinking.

Answer 5

Before anything, be specific about what parts of LINQ you want to them to adapt to.

In general, to create change, you'd have to define what they're already using, the problems they're having, the ways LINQ could solve those problems, how much of a increase in performance they could have with LINQ based on your assessment. You can't expect to bring them something unknown and have them see the big picture. You'll have to bring them that picture.

Answer 6

In my experience, some development groups tend to dislike LINQ. Of those I've encountered who don't like it or who don't want to use it, there have been 3 types. I'm primarily referring to LINQ to SQL/Entities/XML here.

First, there are those who're using other/older object management methods like CSLA or Microsoft Enterprise Library. They're comfortable with this, have time invested in it and don't want to disrupt their existing work by adding in LINQ.

Second, there are those who're more "hands on" thinking coders who see LINQ as a something a 'real' programmer wouldn't do, sort of a cheat or shortcut. One I ran into was even against using built-in generics and IEnumerable objects in favor of coding these algorithms themselves. This seems most common among ex-C++ programmers.

Third, there are those who're still thinking in terms of 10-12 years ago VB6 client-server programming even though they're coding it in C#. LINQ scares and confuses them.

I don't know if your organization falls into any of these. The first one at least holds out hope that you can move toward LINQ in some new development. You may also be able to show them some of the advantages of LINQ to Objects and get them more comfortable with it. The other two are more difficult and you'll face resistance in moving them in the LINQ direction, even in a small way.

Answer 7

If it doesnt alter the external dependencies, I dont see why they would need to micromanage this in the first place. Your first mistake was probably asking them. Personally, I'd just use it. When they see you can get the job done with a tenth of the code others are using, they'll come along. 'course, you better be darn sure it will end up better than the current approach being used.