A Case For and Against the Enterprise Library

I've been an architect for a while now, but, as far as being an architect within the walls of Microsoft, today was day one.

Already, I've run into an interesting issue: when it is better to forgo the code of the Enterprise Library and roll your own, vs. using existing code.

Roll your own what?  Well, the MS Enterprise Library is a set of source code (in both VB.Net and C#) that provides an infrastructure for business applications.  The "blocks" that are provided include: caching, configuration, data access and instrumentation, among others.

I know that many people have downloaded the application blocks.  I don't know how many people are using them.  I suspect far fewer.

I took a look at the blocks myself, and my first impression: unnecessary complexity.  Big time.  This is what comes of creating a framework without the business requirements to actually use it.  To say that the code has a high "bus" factor is a bit deceptive, because along with the code comes ample documentation that should mitigate the difficulty that will inevitably come from attempt to use them.

On the other hand, the code is there and it works.  If you have a project that needs a data access layer, why write a new one when a perfectly workable, and debugged, application block exists for it? 

Why indeed.  I had a long discussion with a developer today about using these blocks.  I will try to recount each of the discussion points:

1. The blocks are complex and we only need to do something simple.  True: the blocks are complex, but the amount of time needed to do something simple is FAR greater than the amount of time needed to understand how to configure the blocks.  If you look at simple project impact, using something complex is still less expensive that writing something simple.
2. We don't know these application blocks, so it will take time to learn.  True: but if you write new code, the only person who knows it, when you are done, it you.  Everyone else has to read the documentation.  You'd be hard pressed to come up with better documentation than the docs delivered with the application blocks.
3. The code we write will meet our needs better because we are doing "special" stuff.  False: the stuff that is done in the application blocks is pure infrastructure.  As an architect, I carry the mantra: leverage existing systems first, then buy for competitive parity, and lastly build for competitve advantage.  You will not normally provide your employer with a competitive advantage by writing your own code in infrastructure.  You are more likely to get competitive advantage by using the blocks, since they will be less expensive with capabilities right out of the box.
4. We don't need all that code.  True.  Don't use the functionality you don't need.  The cost is very low to ignore the functionality you don't need.  More importantly, writing your own code means debugging your own code.  If you leverage the code that is there, you will not have to debug it.  That saves buckets of time.
5. Our code can be tuned and is faster than the code in the Enterprise Library.  The code in the Enterprise Library is tuned for flexibility, not speed.  This is true.  However, when you first write your own code, it is slow.  It gets faster when you tune it.  Why not jump right to the tuning step?  Put in the EL for the component you are interested in, run a stress test against it, and fine-tune the code to speed it up.  You have unit tests already in place to prove that your tuning work won't break the functionality (highly valuable when doing perf testing). 

Please... can someone else come up with any better arguments for NOT using the application blocks in the enterprise library?  I'm not seeing one.