I have been working on this blog post for around six months. I keep writing and shelving it. Today I read a blog post from the DexExpress CTO that got me back to wanting to publish this post.
Early Adopters?
To put what Julian said in different terms; Do you want all the Early Adopters for your product? There are pro and con arguments to having the early adopters when it comes to technology.
While they tend to be some of the most passionate people out there, and they are usually eager to play with a technology but have little to no loyalty to that technology. By the time you have stabilized your product cycle they will be long gone on to the next technology buzzword to play with it.
They also tend to have the most harsh reviews of the early technology. They will bash it as not complete, or not like product x, etc. But by the time you have addressed their issues they will never come back to update those huge blog rants they did against you in the early days. Their social media contracts tend to be very one sided – whatever is in it for them today. After all anyone on the Internet can post a blog slamming a product or technology as inferior. You don’t need credentials or facts to back you up. Just post it – people will believe it. And if the company actually listens to you and implements your suggestions you can always shrug them off as not being “agile” enough for you (IE, they didn’t give you that build the same day you asked for it).
Buzz word and gone
Microsoft is great at playing into this early adopter hype. They print magazines with all their buzz word laden technologies sometimes years before you or I will be able to put it into production. And by the time you do get around to wanting to use it in production they have often already abandoned it for another, newer, faster, more buzz word laden system.
Look at Windows Workflow (WF). Anyone who early adopted it is probably kicking themselves now. Microsoft has basically punched reset on the entire design. I really looked at implementing VistaDB serializers for WF.
They can’t remove it from the framework!
And to all the people who use the argument that they can’t remove it from the framework - that is just silly. LINQ 2 SQL (L2S) is a good example of this. Microsoft printed tons of material about it, but you weren’t supposed to take it seriously. It was just until the more serious Entity Framework came along, didn’t you know?
Well, from the number of articles, books, etc I don’t think anyone understood that argument. So if you did buy into that technology what about .Net 4? Well, Microsoft has said that L2S will exist in some capacity, but what does that mean? To me it means it means you had better be embracing .Net 3.5 SP1 for a very long time.
If your favorite buzzword technology was implemented in a SP how stable is that to actually deploy? I know lots of shops that still refuse to deploy .NET 3.5 SP1 because of the problems they had with the “Service Pack” changing how things worked for their applications.
Sync Services
We actually got bit by Sync Services rewrites three times before we stopped. Is it stable today? I don’t think so. From what I have read on the renamed and polished Sync Framework (as it is now being called) it is still being tweaked and changed. There are lots of people pushing for changes for it to support Azure (ahem, aka cloud computing, aka SQL Server in the Cloud, whatever they want to call it today).
Got Entity Framework?
I have gotten a number of emails from users wanting to look at our Entity Framework (EF) provider. After all didn’t we talk about it late last year? Yes, and we did implement it. The entire VistaDB EF provider is complete. But we will not ship it until we know it performs good enough, and that it will be around for us to support our customers.
Ship it!
So why not ship it? Why not give it to all those people who want it? Why not ride that Early Adopter wave?
Basically, because I won’t do that to you. I actually care about the technologies and interfaces we unleash on customers. I want to ensure whatever technology we present publicly as an interface is stable and not going to go away on you without warning.
We have been making lots of changes in the engine to support patterns that are particular only to the EF provider. They are not complete, and may not be by the time we release 4.0. There are just a lot of strange behaviors in the way it works because it is LINQ based – not relational based. We want to ensure that the majority of the common patterns are handled with decent performance, and then continue to improve the engine over the lifetime of 4.x.
What type of mismatch?
All ORMs exhibit a mismatch when they are mapped onto relational data. It is known as the Relational Impedance Mismatch and all ORMs have it to some extent.
An example of the problem in real world terms: If you have a group of objects you might like to foreach() over them to do something. With Entity Framework that might result in thousands of round trips to your database to answer each of those foreach iterations with one single query. You are much better off to work on a result set and pair things using set operators. EF is supposed to provide for this scenario through DataSets, but it is actually highly dependent on what code the programmer actually wrote. If the programmer does not understand what the framework is going to generate they can beat the crap out of database connections.
We have found some common CLR coding patterns that translate horribly to EF generated database calls. We have to address these issues before we ship something.
Support and Documentation Problems
Another problem with EF is the documentation. We are an ADO.NET compliant database engine. That means if you understand ADO.NET patterns and practices you can pick up our engine very easily. There is no such level of competency with EF. Everyone will be in a huge learning curve. Most of the documentation you find for LINQ is around Linq2SQL syntax (which is NOT the same). And to make it worse that L2S syntax will compile and blow up and runtime in most cases with very bizarre runtime errors. This would cause a huge support load on us. I cannot imagine how we would be able to keep up with those types of tickets when most of the issues have nothing to do with us, but the EF framework itself.
So if we ship an EF provider we are in effect having to support the entire EF framework including tools designers and runtime. That is a REALLY tall order for a small company.
Entity Framework Stability
So if we are going to have to support it, how stable is it? In my experience of our online store and related tools it has a ways to go for stable. I still have to regen our store edml model about once a month because Visual Studio somehow corrupted it or got out of sync. I also still have the GUI wizard in Visual Studio crash on me regularly. And this is all when working with SQL Server.
Who do you think is going to get those tickets if they were working with our EF Provider? We would, and there is nothing we can do to fix them.
I know of five companies that started using EF last fall for major projects. Out of those five only one is still using it in any way. All of them abandoned it for their main DAL, but one was still using it for internal tools and utilities. That tells me the framework has a ways to go for widespread adoption.
When will we ship it?
The current plan (and this is of course subject to change) is to start preview builds of 4.0 shortly after we ship 3.6. VistaDB 3.6 is feature complete at this point. We are just working on the samples and fine tuning the installer.
Rather than release VistaDB 3.7 we are going to start releasing VistaDB 4 preview builds. I will post more information on what that means in engine terms later, but our plans are to release a series of preview builds and then ship a stable around the October timeframe.
There are two things that have to happen for us to ship an EF provider.
One is that I have to see the .Net 4 EF model and know we are not going to be required to totally rework our existing code. If we have to rewrite then I will never release the current provider. It would be a waste of time to ship something that is obsolete almost as soon as it is released. I want to make sure we can support the VistaDB EF Provider for a minimum of 2 years.
The second is the Visual Studio 2010 plugin model specifications. Right now our current plugins do not work with VS 2010. If Microsoft is going to leave the current model in place and require us to update the designers then we will have to create a new build for VS 2010.
Visual Studio Support
We cannot afford to support three versions of Visual Studio (each with it’s own designer) at the same time, so it would mean a drop of VS 2005 support for VistaDB 4. I don’t want to do that. I am hoping that Microsoft fixes their current issues, or publishes a way for third parties to not have to build multiple plugins to support different Visual Studio editions.
I don’t think that Visual Studio 2010 is going to be a runaway adoption from day one. I find that a lot of companies are just now migrating to Visual Studio 2008, but many are sticking with 2005 and hoping to leapfrog directly to 2010. But it comes back to that Early Adopter statement above. Those users who adopt Visual Studio 2010 early are going to be vocal users.
.NET 3.5 SP1 or 4 support?
You can’t build an EF provider without using .Net 3.5 SP1 – it simply didn’t exist before that time. That means you are dependant on a SP being present. (WHY, oh WHY didn’t they call it 3.6 since it added so many new features!) This means we have to ship a .Net 3.5 SP1 assembly to support EF. Would you do that and commit to that SP for the next 2 years, or wait for .Net 4?
There are a lot of great things in the .Net 4 framework. We would love to take advantage of them, but you just can’t do that without also maintaining .Net 2 versions at this time. I do eventually think that .Net 4 will replace the current .Net 2 stable that most people use. I think a lot of companies are going to jump straight to 4 from 2 when they finally switch their compile targets. And that means the version of Entity Framework in .Net 4 is a very serious factor for us in what to support in VistaDB.
Right now I think we are leaning towards 3.x staying a .NET 2 assembly without Entity Framework Support. Then stepping up to .NET 3.5 SP1 for VistaDB 4 with EF. That would mean no Visual Studio 2010 support in the initial releases unless Microsoft changes something.
What are you doing?
What about you? What are you doing with regards to .Net versions and Visual Studio? Are you going to start shipping 3.5 SP1 tied assemblies? Or would you rather wait for 4?
Is your company still shipping 2.0 assemblies today and skipping .NET 3 entirely?
I hope this has provided a little glimpse into how complicated it is for us to decide how and when to ship things. It is never easy, but the entire .Net 3 product cycle has thrown a lot of our plans into a spin.
Subscribe