Avoid eye contact with Enterprise Library.

Ballchain I travel quite a lot. In fact it is rare that I don’t catch at least one or two flights a month, and based on recent form it is more like one or two flights a week. One of the constants at airports at the moment seem to be the credit card spruikers from AMEX and Citibank who use a number of tricks to get you to walk over to them. A classic example is exploiting an unsuspecting travelers need to be polite and respond to some kind of enquiry.

After enough wasted time experienced travelers learn to ignore the initiated conversations in the concourse and focus on getting from the gate to the taxi as fast as possible, they either completely blank the sales person or they walk on the opposite site of the concourse to avoid contact being made at all.

Getting from the gate to the taxi is kind of like a software project. There are things that you have to do, and things that you don’t have to do, and a whole heap of shiny distractions to slow you down. In a software project one of the common things that seems to come up is what “framework” are we going to use. This usually dissolves into a discussion about building your own or adopting something like Enterprise Library or the myriad of other freely available frameworks that have popped up over the years.

I’ve already got a framework!

Darren started a discussion about his thoughts on Enterprise Library, but I actually think that there is a meta-point to be made here. When we choose a development platform we choose not only a runtime (assuming a managed environment) but also a set of base class libraries (or in the case of .NET a BCL plus a number of additional frameworks like ASP.NET, WCF, WPF and WF).

For me, I need a lot of convincing that something like Enterprise Library is going to give me a lot on top of these frameworks to accept the mammoth amount of code that I am going to be responsible for when I integrate it into my code base. And before you jump in and list all the features – they actually need to be features that *I* need, not some mythical piece of software that what I am building today might turn into – someday.

The meta-point is that we are already sitting on top of a very capable and well factored framework, in most cases Enterprise Library just wraps or aggregates existing framework functionality in a way that introduces so much complexity that it actually detracts from the productivity of developers. If Enterprise Library did more than put managed wrappers around existing managed wrappers then you might have an argument, but other than some corner cases in cryptography it doesn’t give you much more than an existing .NET developer could build by using what is in the System.* namespaces.

Keep your eye on the goal!

When writing code, there are lots of things that can distract developers focusing on the needs of the end-user. Regard things like Enterprise Library with the same suspicion I do when I spot a spruiker at the airport, even if they use shiny words like “enterprise” (meaning if you don’t do this you aren’t enterprisy enough) and “library” (meaning that if you don’t use this your code isn’t reusable enough).


4 thoughts on “Avoid eye contact with Enterprise Library.

  1. Kevin Daly

    Normally I would take this as a cue for yet another intemperate rant, but just for variety, today I will merely say: I agree entirely.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s