Tuesday, June 24, 2008

Rejoinder #1 to "Vote of No Confidence in Entity Framework"

There's a "vote of no confidence" in Entity Framework petition that is circulating and, as I write this, it has drawn signatures of some 156 people. Many of them are well known, deservingly respected, and some of them I consider friends.

But this petition is wildly misleading. The dire warnings of "potential risks .. to Microsoft customer projects" are blown way out of proportion. It is one thing to be critical of EF v.1 - to draw attention to its shortcomings as we all have done - and quite another to consign it to damnation.

Tim Mallalieu, the new PM for Entity Framework, has written a careful response in the measured tones that befit a Microsoft representative. I, on the other hand, am not bound by such restraints and am free to indulge such rhetorical flourishes as suit my mood and temperament.

At the moment, I'm hopping mad. Every two-bit architect with visions of grandeur is going to send this petition to his boss as proof that Entity Framework will doom the project.

Hey boss, all these MVPs are against Entity Framework. Let me write our application with Domain Driven Design. I don't know a thing about it but how hard can it be? Of course I'll have to learn nHibernate first. Not sure how I'm going to do that. I can't seem to find a book on it. The documentation looks ok though. Well ... yeah .. I haven't found any examples or guidance on how to build a real application with it. But I'm an architect ... I'll figure it out.

Six months later our budding genius proudly shows off his ugly baby: some undocumented, impenetrable morass that only he understands and that works "most of the time", just not while you're watching. The application itself?  "Ah ... it's coming ... honest."

We've seen this over and over again and it is no accident. Some of my company's best customers found us after they cratered their first attempts with nHibernate.

I am not saying this is nHibernate's fault. It's great stuff in skilled and experienced hands. I am saying that there are risks with any choice of a profound technology and, before I lecture you on the "potential future risk to your projects," I would do well to find out about your business - and your developers - first.

Now I think there is a ton of merit to many of the criticisms of EF in that petition and much more to learn independently from the petition signatories.

But these folks are not coming clean about your prospects for building with some unnamed "something else." And, I submit, the chances of your success with EF are vastly better than with many of the alternatives that you are likely to hear about or pursue (including continuing with a traditional ADO.NET approach if that's what you're doing today).

Yes, I'm making a generalization without knowing anything at all about you or your business. And if you give me another minute, I'll tell you why you'll want my company's value-add product for Entity Framework. But before I get ahead of myself, let me try these thoughts on you:

  • EF is going to mop the floor with all of the niche players. It will become the "standard" in this space. You want to throw yourself and your employer against that buzz saw? You better be able to show that something horrible is going to happen if you use EF instead. It is not enough to argue that technology 'X' is better. You have to show that the long term ROI of building with your pet technology is vastly superior to building with EF. You'll have to show that the EF defects identified in that petition are going to spell disaster for your project. Frankly, I don't think you can make either case. I'm not challenging your intelligence or persuasiveness. I'm saying the case is not there.
  • There are thousands of successful applications built with frameworks like Entity Framework. I'm defining "success" here in soft business terms as in "the business likes it and thinks you are doing a great job". Don't stack the deck against me with Fitness tests (which are great, btw, but not implemented in most shops and irrelevant to the argument). Ultimately, business satisfaction is what we're striving for.
  • We have zero empirical evidence that actually existing applications built with pure Persistence Ignorance frameworks are intrinsically more successful than applications built with Persistence Aware frameworks.
  • On the other hand, there is good evidence that Persistence Aware frameworks are (a) easier to use and (b) result in earlier delivery of useable applications. You can start coding against an EF entity model almost out of the box. I'm not saying you should ... but you can. The fair proponents of Persistence Ignorance always acknowledge this when they talk about the "trade-offs" of PI.
  • EF isn't even released and there is already more of an eco-system surrounding EF than around all of its competitors combined. Count the forum entries, magazine articles, and blog posts. Count the books on Amazon (six so far; ok, most not released yet ... but try to find a single published book on nHibernate).
  • Expertise in EF will emerge quickly and spread widely as it always does with MS technologies. You will struggle today to find affordable developers and consultants who know about the rival niche technology of your choice; that situation is unlikely to improve as EF gains traction. 
  • Some people will be good at developing with EF; some will be awful. But this is a numbers game and you can be an atrocious nHibernate developer too. The difference is that you will be able to find someone who can tell you that you have an EF fraud in your organization; nHibernate charlatans can hide like roaches.

... and from the "damning with faint praise" department ...

  • I  eagerly accept that the evidence is overwhelmingly in favor of tested applications. EF is not unit test friendly (to put it mildly) and that's bad. They could have ... and should have ... addressed this in version one. But (a) you don't have to be PI to be unit testable and (b) you can build EF Domain Models that are unit testable (no visits to a database) as I will explain in a later post.   
  • You can build your app with a DDD perspective ... you'll just have to work harder than you ought to.

Sure, I'm a proponent with an investment in EF (our new product is built on it). But the signatories to this petition are stained by compromises of their own. Many of them have deep emotional and even financial interests in rival "platforms" such as nHibernate (you have a financial interest if you've been paid to build an application with nHibernate).

Our little corner of the world would be better served if the petitioners rallied to (a) help customers make the best of EF version one and (b) got busy helping Microsoft improve it in version two.

---

Watch for a future blog when I examine the petitioners' "unresolved issues", point by point. They have merit. But they are not decisive objections and you can mitigate the problems, often with little pain.

Somehow I find I cannot end this post without dipping my toe into these waters. Let me start with the big one, DDD.

The petition avers that Entity Framework inhibits sound application architecture through its data-centric approach to mapping and code generation. We should be using Domain Driven Design and you can't do that with EF, so they say.

Eric Evans wrote the book on Domain Driven Design. It's a fantastic book; get it, read it, adopt it. Whether you're dealing with an existing database or starting afresh, you can benefit from Evans acute observations and analysis. But DDD is not a panacea and it is not trivial to apply.

Unlike his acolytes, Evans is the first to say that Domain Driven Design is hard. His is a book on perspective not on technique. Over and over he cautions that there is no machine for cranking out DDD applications. The practice of DDD is a relentless reexamination of the business problem and your implementation of it, punctuated by flashes of insight. What this book does is (a) prepare you for insights and (b) provide intellectual tools for unearthing and recognizing those insights.

Of course what does the industry do? It turns DDD into a cook book! You'll have little trouble finding someone with an MVP tacked to the end of his name, bloviating on DDD and what he knows that you don't.

Evans also makes the point ... several times ... that you don't have to adopt a particular data access infrastructure to build a Domain Model. Sometimes it makes sense, he says, to go with the infrastructure you have and bend it to your needs. Ideal? No. But serviceable unless the infrastructure is just crap.

For sure you do not enter DDD heaven simply by writing your domain objects before you write your database schema. Nor can any priest excommunicate you from the church of DDD because you map and generate Entities from your schema.

More soon ...

Update 6/25/2008 Added below:

I am looking forward to responding to the comments I've received so far, all of them remarkably well mannered. I'm going to get back to you all when I have a moment to breath. Meanwhile, I just want to direct your attention to these fine folks:

Tim Mallalieu, PM for Entity Framework, wrote the official Microsoft response and is showing a lot of love to the Persistence Ignorance fans these days on his blog and on the EF Design blog.

Microsoft's Elisa Flasko offers her views on her blog.

Roger Jennings has been following EF for a long time. He's been bulldogging links to "the vote" - adding his own appraisals of each - on his blog. He can save you a ton of time if you're trying to stay on top of what's happening in EF world.

Here's a shout out to Julie Lerman whose been in tireless pursuit of matters EF and who first clued me in to the vote in this post. She's a wonderful, level-headed resource on EF and a pleasure to read. Awful nice in person too.

Update 12/17/2008

I finally got around to addressing the five points of the "No Confidence Vote". I did so in a reply to Scott Bellware's comments on my  post, Is Entity Framework For Real?

11 comments:

Jimmy Bogard said...

Let me tell you, I'm glad we have folks with some different perspective.

- EF is going to mop the floor with all of the niche players.

Maybe, maybe not. Depends on how good it will be. Standards last only as long as they're appropriate, just as we're seeing SProc-centric apps on the decline.

Personally, I hope a great EF becomes the standard.

As for ROI, no one shows that with EF or any other technology for that matter.

- There are thousands of successful applications built with frameworks like Entity Framework.

Yep, and I've had to rewrite a couple of them. So many factors contribute to success, ability to react to market change has to be at the top. Something that couples me tightly to designers doesn't.

- We have zero empirical evidence that actually existing applications built with pure Persistence Ignorance frameworks are intrinsically more successful than applications built with Persistence Aware frameworks.

You have zero empirical evidence the other way, too. Lots of anecdotal evidence either way too.

- On the other hand, there is good evidence that Persistence Aware frameworks are (a) easier to use and (b) result in earlier delivery of useable applications.

We deliver PI apps after one iteration (one week). Maintainability and consistent velocity is my concern. Designers don't allow this.

- EF isn't even released and there is already more of an eco-system surrounding EF than around all of its competitors combined

Yes, many folks looking to make money by writing books, become MVPs etc. New technologies are a magnet for those looking to capitalize on a new niche. Volume does not equal quality.

- Expertise in EF will emerge quickly and spread widely as it always does with MS technologies.

Yes. This is a very good thing. Someone has to answer my google searches for the obscure problems.

- Some people will be good at developing with EF; some will be awful.

This isn't an NHib vs. EF discussion. All those that wrote the letter are happy to give up NHib for something better. It just doesn't exist yet.

I'm worried that the default architecture leads to lack of maintainability, as Web Forms does. It just asks you to put everything in the Page_Load.

------

It's absolutely important to question the motives behind the signatories. I've made money from developing from NHibernate, and made more money mopping up after typed DataSets.

I'd say the financial advantage cuts both ways. I've run into so many technical books that offer no discussion on when and why.

This letter can be nothing but a good thing. It's already opened up the dialog, and the work of those involved in the letter led to the EF team even knowing about DDD. Before the preview early last year to the letter writers, there was no connection to DDD in the EF team.

I wish you success with your EF product. EF has so much potential, I hope it's not compromised by those motivated by selling books and speaking at conferences.

Anonymous said...

Great post -some of the approaches taken by the anti-EF crowd are beginning to degrade my respect of them - as well as question their motives (not that I'm sure they care :-).

Oh - and where do I sign?

Unknown said...

Hi Ward. You've got an interesting perspective as someone building commercial tools on EF. I was in that role for a while early on as well. I did switch back to nHibernate though. We used DDD patterns for both. I've used nHibernate in more active record styled, persistence aware configurations as well.

I hope we get a chance to meet in person one day and talk over some of these things in a higher bandwidth context.

Chad Myers said...

Your argument seems to be 'Not a lot of people know DDD or nHibernate, so we should stick with sub-optimal stuff because it's what we know'? That's a pretty sad view of things. Isn't it time we finally move beyond the 80's-era big-database-up-front mentality and model application and data separate and take advantage of the strengths and ditch the weaknesses of each rather than trying to force everything into an RDBMS mindset?

As to EF mopping the floor, ASP.NET WebForms mopped the floor and it was proven to be mostly harmful for maintainability. It's enabled lots of money-making, but has had it's fair share of money-costing in terms of poor maintainability, no testability, etc. And MS is coming around here and doing things like MS MVC. MonoRail has also been fairly popular as of late.

Just because MS puts out EF and it has a good adoption rate doesn't mean we shouldn't fight the good fight against tools that harm more than they help.

I'm not saying DDD/nHib is the Holy Grail either, but I'm definitely saying that EF is a step in the wrong direction until, at least, v2.0 and then we will have basically accomplished what was already done 5 years ago.

Anonymous said...

I want to add two points
a) a book 'bout NHibernate is coming : "NHibernate in Action (Pierre Henri Kuate, Christian Bauer, Gavin King)" (Manning pub)
b) Never discuss version 1.0 of a MS product (Windows / Office / Sql server / ...). Just wait a version or two and see what happens then.

Anonymous said...

Thanks for a practical and clear perspective. I'm agree totally on the "ecosystem" argument, that EF will grow into being the dominent ORM player, especially with the tools and LINQ technologies being developed around it.

And, yes, I admit it, I love using tools for coding. One shouldn't feel ashamed of not hard coding. So that's why EF is very appealing.

Anonymous said...

Great post Ward. This is very pragmatic perspective, and one that I think is shared by many. You make some very salient points which are hard to refute. As Jimmy said there are lots of anecdotal evidence all around.

At the end of the day whether or not EF is great doesn't really matter. Whether it fully supports test-driven-development doesn't even matter, though it would be great it if it did

What matters is that customers can succesfully build solutions with it that the ROI. If it does not do that, then it has failed.

The vote of no confidence is a reflection of a belief from a segment of the community that this failure is imminent.

Personally I am on the fence. I personally prefer and see the value of persistance ignorance, testability, etc. But I can't equate not having that to failure, just as I can't equate that not developing with TDD means devloping bad software.

Time will tell.

I am optimistic about Tim's recent post on opening up the design of V2. Whether EF is there now or not, having visibility and the right feedback loop in the next version is definately moving in the right direction.

Ward Bell said...

All - Thanks for your comments including the respectful disagreements. I agree with Scott when he observes that blog comments are a difficult format; to your credit you all tried anyway.

I was pretty hot when I wrote this post. Had the "vote" been presented as "A collective expression of serious concerns" I would have responded differently. But here was an assault that urged people to avoid EF ... and that is overreaching we don't need.

I responded with counter claims about EF productivity that are every bit as anecdotal and unsubstantiated as the claims in the vote.

I don't doubt that Jimmy has had to swoop in to fix apps written with Typed Datasets (not my idea of ORM but undeniably a RAD approach) just as we have rescued NHib failures. It's impossible to derive conclusions from such evidence.

That said, I think the burden of proof falls more heavily on the "vote" supporters to document the "doom" that looms over anyone who adopts EF.

@Jimmy - I respectfully suggest that you have not made the case that Designers obstruct maintainability or velocity merely by asserting that case. Lead me to something more substantial please.

@Chad - I keep hearing you say that MS offers "tools that harm more than they help". Where's your evidence of harm? It seems to me that the most brainless use of EF is better than what most people are doing today. You cannot expect the masses to take up NHib and DDD in their present state. These two are not well enough "productized" to be adopted. If they were going to be adopted, they would have been. No one blocked them.

It matters ... it matters a lot that Microsoft is bringing ORM into the mainstream as NHib, IdeaBlade, LLBLGen, WORM and others ... on the evidence ... could not despite years of trying.

Do you think Microsoft could have copied NHib? Or should have? I didn't think so.

EF is progress and, in my view, can be used for "good" when supplemented ... as it will be ... with guidance and value-added products. There are ways to mitigate its deficiencies until v.2. Let's get going on those mitigations.

Moving on. Let's dispense with the fiction that talking about NHib is somehow besides the point. NHib is the voter's unspoken stalking horse. I don't doubt the sincerety of those who claim they are eager for something better and had hoped EF would be that something. That still leaves NHib as the "other" in this discussion.

I held that it is very hard to learn how to write in PI fashion with NHib. I have since tested this proposition with more investigation (e.g., asking Ayende for leads, re-reading NHib documentation, searching for guidance in the usual ways); I find my assertion confirmed. This when the technology in question has been in place for at least four years.

So what is the response? That EF will inspire money-hungry writers eager for self-advancement. This is bad because ... why? Self-interest ensures authors will do a bad job explaining EF? Self-interest ensures that people who write about EF won't talk about "when and why" to use it? Self-interest ensures a conspiracy to paper over EF's problems?

This is absurd. I maintain on purely economic grounds, that there will be market for solid critique as well as your expected apologetics. A fair reading of the EF commentariat to date shows a far greater critical faculty than I've been able to discover surrounding NHib.

So far, I've found nothing remotely like mainstream critical commentary and the "when and why" on NHib. Sure, if you ply the blogosphere, you can ferret out a juicy bit here and there. But there is nothing to compare with the openly critical and evaluative observations about EF that you'll find even in Visual Studio, CoDe, or MSDN magazines.

Please spare us the sneer that EF has more to explain and complain about than NHib.

Spend a little time with NHib XML in try to sing its praises. Consider the lunacy of having to say "SaveOrUpdate" when what you mean is "Attach". Peek at the NHib implementation itself and try not to shudder. How about the copy-paste job that cribbed paragraphs of Java references from the Hibernate docs and dropped them untouched into the NHib pdf? "Maturity" is not the word that springs to my mind.

Who can read the documentation's "Best Practices" section without astonishment. I'm still aghast that NHib voids your entire UnitOfWork if the persistence layer throws an exception; you must rollback and discard all the user's changes - a practice the author concedes is "more of a necessary practice than a 'best' practice".

You want to prove me wrong? You think that NHib is ready for prime time? Please point to something.

You can forget about referencing the obscure forums and blog posts. That's not how an industrial grade infrastructure is learned or supported.

Remember, my claim is that EF spawns a large, easily discovered, multi-voiced community of knowledgable writers - some of whom are MVPs (gasp) just like the voters. That community is building already. So where is the comparable NHib community? And why can't an ordinary mortal find that stuff?

Let me say this. As EF has approached release, there has been a surge of independent and better produced NHib support. There are a bunch of NHib videos in the works. Ayende is trying hard. This is a great thing.

Nonetheless, such efforts linger far behind what you will find on EF today and will soon find in greater abundance.

Let me end on a conciliatory note. The "voters" do have legitimate concerns. Every one of the specific EF defects identified in the letter are real problems. I may disagree with the implications of those problems, but I agree that they are real problems and the EF team should take heed.

I think the EF team does not yet appreciate that spewing getters and setters is no substitute for a careful analysis of the business problem that should determine the public face of the domain model. I don't know what they should do about that exactly ... because I think the value of generating code overwhelms the risk of oversimplifying the modeling process. But we - if not EF - should do more to emphasize design first.

The lack of testability and plugability in EF is a shame that could have been and should have been avoided.

And, yes, the sheer market bulk of EF threatens to eclipse what many have learned the hard way through practice of DDD with NHib.

I commend the voters who are fighting for all of us when they protest that EF is (a) disappointing in important respects and (b) inhibits many widely accepted practices. Without their leadership, these objections might easily disappear in the marketing fog that must accompany EF's successful release.

So keep swinging. You're helping to make EF better for all of us.

Just don't throw the baby out with the bath water. And please, lighten up on disparaging those of us who must mix metaphors and see a glass half full.

Malcolm Young said...

Hi Ward,

First let me start by saying I have no idea who you are, what you do or anything else about you.

Secondly, let me commend you on this piece. It is clearly the most erudite and concise post on this topic I have read anywhere.

Finally, let me say thanks that there are still professionals like you around as opposed to the fanatical, smart-arse primadonnas that seem to have overtaken our profession over the last ten years.

mal
Not related to MS in any way, just a tech manager that needs to build products in the real world.

Anonymous said...

This is great info to know.

Bleenq said...

As I begin to explore EF (having grown further dismayed by NHibernate and it's WCF Integration) I come to wonder how EF and Workflow Foundation are intended to mix. Any ideas?