Microsoft Says LINQ to SQL Not Dead

While some I spoke with are coming to terms with it, others are angry. "I feel stabbed in the back by this but I'm not moving," said Howard Richards a principal with UK-development firm Conficient, who says he invested a year with LINQ to SQL and now feels blind sided. "What annoys me most is Microsoft's cavalier attitude to its developers in this regard. It took me six months to port my application from a 'homebrew' data layer to LINQ to SQL."

Yesterday I spoke with Tim Mallalieu, the program manager for both LINQ to SQL and the Entity Framework, who says Microsoft anticipated the backlash but said both data access interfaces will be better off for this move. For those who don't think the Entity Framework is a suitable replacement, Mallalieu said stay tuned.

"There's some pretty nifty stuff we're doing in the beta 2 time frame that we are not speaking about as yet, I think it will give you a better experience and will reduce the anxiety that people have around the Entity Framework," Mallalieu said. "In terms of capabilities, I think will make the overall integrated experience of ASP.NET, Dynamic Data, MVC and these other things easier, we did a little bit of triaging and feedback, there is some valid feedback around complexity in the Entity Framework and we are doing things to address that. "

What follows is an edited transcript of our conversation.

How widely deployed is LINQ to SQL today?
All indications were that it was like any nascent technology, there was a lot of interest from an exploratory perspective but there wasn't a lot of significant -- in terms of the entire .NET eco system -- pushes going into production. There were a bunch of people kicking the tires, there were some pretty interesting things going into production. We are still trying to get a better way in general in the company to gauge technology adoption, but today, I can't give you a definitive number.

Were you surprised at the reaction?
We knew that this wasn't going to be a popular decision just because LINQ to SQL is a really interesting technology. It's very nice. The problem is though, when you make a decision like this, you can either say we don't want to [tick] off the community, which means that you get a bunch of people just betting on the technology to a level which will not meet with their expectations of future innovation, release after release. Or you could actually take the hit and get the tomatoes thrown at you early in an effort to do right by the customers. So what we were trying to do, maybe we could have done it better, is to do right by the customer and set expectations early for where we were going.

For those who say this was a political decision and not a technology decision, is that an unfair characterization?
There were a number of political aspects to why we released two technologies to begin with but in the grand scheme, what we were trying to do with the .NET Framework right now was to reduce the amount of overlapping technologies that we keep on dumping out as opposed to increasing the number. We convinced ourselves internally that it was okay to release LINQ to SQL and Entity Framework because there was clear differentiation between the two, and the markets we were going to go after were different.

The reality is if you go look at what people are asking for, the rate of convergence from a feature set perspective of the two stacks was two releases away from convergence. So you look at that and say we could spin up two teams of equal size to go do this work, and within two releases you are talking about two stacks that look almost exactly alike, or you can say one of these technologies has already been identified as a strategic piece of a bigger data platform vision. From a shared investment perspective and technology roadmap perspective, it seemed like the right thing to do. The problem is because there were some initial conflicts that people have rumbled about from the history of the two technologies, it's hard to see that there was actually an attempt to make pragmatic decisions that were not covered by any political intentions.

If you had two technologies that were covering the ORM space, and one was pretty nifty, was very fast, lightweight but people were saying they wanted things like a provider model people were saying they wanted things like many-to-many relationships, people were saying they wanted the more complex inheritance mapping but you said there's another technology that has already done that stuff and we think is the foundation for a broader data platform vision, would you build those features into the other technology, or would you say, "it sounds like what people are saying they want all of those scenarios but they want the added simplicity"? So from a roadmap perspective it just did not make sense to duplicate efforts from in two code basis.

What can you say to those who feel stabbed in the back or duped by this change in strategy?
There are few things I can say that will actually make it better. But as soon as we came to the decision, we felt the best thing to do was to come up early and tell people so they understood what the situation was as opposed to playing them alone. I think it would have been much more painful to wait two years to be talking about why we weren't investing at that level in the technology. We expect that people will continue to develop with LINQ to SQL, it's a great technology, we are going to provide with the patterns and practices group in Microsoft for how to design LINQ to SQL so if you are happy with them, you just stay with it. If you at some point after using LINQ to SQL want to move to the Entity Framework, hopefully if you follow the guidance that we will give, it won't be as hard to move. You don't just go down a path where you've fallen off a cliff. But beyond that, it's not the kind of message that I can sit here and say something to you that would be a panacea for the community.

In hindsight do you regret releasing LINQ to SQL and not just waiting for the Entity Framework to be ready?
I think LINQ to SQL is a very important technology, it's unfortunate how this is ending up for customers, but I think given where we were from a product perspective and a technology perspective that LINQ to SQL is really important, and I think in it's current existence and with the kinds of work that we expect to do with it moving forward, it's still going to have a good following. It's just not going to be the be-all-and-end-all enterprise O/RM that has every little knob and bell and whistle; quite frankly, if you were to add every little knob and bell and whistle, you'd wake up and find all the elegance and simplicity of LINQ to SQL would be gone.

Do you see there being new LINQ to SQL features?
We see there being new LINQ to SQL features, I don't know if there will be substantial new LINQ to SQL features in .NET 4.0. After .NET 4.0 we have every intention of doing feature work in LINQ to SQL. We are also doing a bunch of bug fixing, servicing, and that kind of work. LINQ to SQL was developed by the C# team, when Visual Studio 2008 .NET Framework 3.5 shipped, there was a transition of the technology into our team. The problem that we had was the transition didn't come with people, it came with just the technology, and we immediately were tying to do work for .NET Framework 3.5 SP1, we wanted to add support for the new SQL Server date types into LINQ to SQL so we focused tactically on SP1 just on getting some of the features and design change requests that the C# team said needed to be in to get the service pack done. That meant that when we shipped the technology we had to officially take ownership of it, which meant we had to get the technology on boarded. We are different teams and have slightly different focuses, and we had to get new people ramped up on the technology, given that .NET Framework 3.5 SP1, released halfway through our development cycle for .NET Framework 4.0, and given the adoption work I just described, it was really hard for us to do any significant work in .NET 4.0, but we intend to do feature work in the future.

Posted by Jeffrey Schwartz on 12/18/2008