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.

  • 3
    Linq-to-SQL or Linq-to-Objects? – Jim G. Dec 14 '11 at 17:04
  • 4
    Are you sure you mean Linq, or Linq2Entities/ADO.NET Entity Framework? Linq, by itself, doesn't equate to databases. – Scott Whitlock Dec 14 '11 at 17:05
  • 5
    I wish we had Linq2Management -> (from m in managers where m.Clue > 0 select m).Any() :) – Scott Whitlock Dec 14 '11 at 17:07
  • 1
    @ScottWhitlock: I would think Linq2Management would sell itself. – Joel Etherton Dec 14 '11 at 17:09
  • 2
    Who is "management?" For many people's definition of "management," management couldn't care less about LINQ, it's just a standard library and/or programming technique if you're already using .NET. Use of LINQ would typically be discussed in an organization's coding standards or best practices. Is it developer teammates or a developer lead you need to sell on this? If so, have a look at Driving Technical Change – nlawalker Dec 14 '11 at 18:07


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):

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.


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.

  • Sql bulk copy is used here. I understand this can be implemented in linq as well. Is linq still faster in this situation, where sql bulk copy is used? – sooprise Dec 14 '11 at 17:13
  • Faster to execute or faster to write? I have no idea if its faster to run (you would need to test it). I suspect its faster to write but that depends on what exactly you need to do. I was being a little more generic – Tom Squires Dec 14 '11 at 17:23
  • It depends on the amount of data, but if it's a lot then nothing is likely to be faster than bulk copy/insert. You should of course follow Tom's advice and profile it to be sure - in fact for any performance sensitive work you should always profile under realistic loads. – FinnNk Dec 14 '11 at 18:02

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).
  • I do not believe PLINQ is included with .NET 4.0 by default. Furthermore what I know about PLINQ is that its not even fully tested by Microsoft ( read work in progress ) and won't be until I believe .NET 4.5 – Ramhound Dec 14 '11 at 19:46
  • You are wrong. It is a part of .Net 4.0 and it is full production version. See MSDN: msdn.microsoft.com/en-us/library/dd460688.aspx – Alexander Galkin Dec 14 '11 at 21:59

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.


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.