If you read this blog with any regularity you know that my workplace adopted CAB a while ago. At the time we were inspecting CAB we looked at a lot of other things; we looked at IoC containers like Spring.Net, PicoContainer.Net, etc. But what we found with the CAB was that it offered more than an IoC container; it offered a whole slew of other features (EventBroker, CommandHandler, Workspaces) that made our lives easier and more productive. It gave us a consistent way to tackle repeating problems.

Today, Ayende decided to bash the Patterns & Practices team at Microsoft. He also took a shot at CAB.

All I can say is I’m terribly disappointed. Ayende’s blog comes through my aggregator and I read his posts every day. Reading his blog is interesting; I don’t always agree with what he says, but many times I do. And often his insight comes from a place of deep knowledge. That’s why I read his blog; because he knows things and doesn’t just spout off uninformed opinions.

At least, until now.

His comments on the CAB appear to come from a place of deep ignorance. They are the same comments I’ve read from other people who have taken a cursory look at the CAB and dismissed it as “too complicated”. Instead of taking the the time to actually grok the technology, they just bash it.

The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily testable and easier to explain to the next developer.

Not worth bothering? Maybe if bothered with, the benefits of the framework would become apparent. It’s possible that Ayende thinks it’s just a bloated IoC container not worthy to lick Castle’s boots. And that would be unfortunate because CAB is way more than an IoC container.

But the part that really puzzles me is the “weight” comment. Now, I’ll concede there’s a learning curve involved with CAB. It takes some time to grok the framework and what it is capable of doing. But once you do, it’s simplicity of use and flexibility makes it very attractive. That said, I don’t think the learning curve is what Ayende is talking about. My guess is that he’s talking about the amount of code included in the framework and the amount of code you have to write to make something work in CAB.

The amount of code in the framework doesn’t seem to me to be any more than any other framework when you take into account that CAB is doing a hell of a lot more than IoC. And the amount of code you have to write to actually make a CAB application work seems like a pittance compared to the benefits you gain from using it.

Then there’s this comment:

The stuff that they release almost always build on the naked CLR, it tries to build on top of that something to ease the pains of people who are working with that. The problem is that if you are doing that, you may be making great strides in making a developer life easier, but you are taking them in the completely wrong direction.

The wrong direction? What direciton would that be? Productive?

I don’t know where Ayende works or what sort of environment he works in, but I know he gets a lot of time to blog and maintain his own open source mock framework. Not everyone has that luxery. We have to get real work done under time constraints. We have customers who expect results yesterday. We’re in the trenches trying to implement features for customers who have unrealistic expectations about when things should get done. That’s just a fact of programming life in many business environments. It doesn’t matter how often we explain Agile to our customers, they still think in terms of deadlines and they want everything now. Anything that helps us achieve our goals is a good thing.

Tools like CAB and Enterprise Library help us achieve our goals in an expedient fashion. That’s the bottom line. They give us a consisten way solve problems.

Yes, we could sit down and write our own framework and it undoubtedly would be more lightweight than the CAB because it would serve just our purposes and not attempt to solve anyone else’s problems. But that takes time. Maybe Ayende is a supergenius ready to take the crown from Marilyn Vos Savant and that’s why he can claim to write his own CAB in half a day, I don’t know. I’d certainly like to see it; I’d like to see a lightweight CAB with all of the CAB’s features written in half a day. That would be impressive.

Mostly, though, I think Ayende just hasn’t done his homework, which seems really out of character for him. He tries to act like he has done his homework:

I am not speaking blindly here, it took me 40 minutes to repreduce the policy injection block.

This brings up a really good point: There are tools out there that can accomplish certain tasks. If Microsoft builds another tool on top of something, which tool should they choose? If the P&P guys were going to build CAB without ObjectBuilder, for instance, then what IoC container should they have used? Would it be a good idea for them to build CAB on top of Castle Windsor? Would that be an endorsement of Windsor that Microsoft would deem unacceptable? Would it be acceptable for them to build Enterprise Library using Castle Windsor?

I can see why P&P builds their own pieces: they don’t want to rely or endorse 3rd party OSS.

The fact that P&P has built their own tools, like ObjectBuilder and the Policy Injection Block, seems like an unfair reason to condemn the whole Enterprise Library. Like saying, “one aspect of this thing sucks, so the whole thing is useless to me.”

Of course, that’s pretty Ayend’s modus operandi. If something is of no value to him personally, it must suck. Even his buddy Roy Osherove had to call him out on that behavior lately.

But what’s more baffling is this comment:

When looking at the stuff that the P&P produce, I see things that are extremely complex to their purpose, hard to use and maintain, and don’t really add any value to me from where I stand today.

When I read Ayende say that the P&P’s tools are “extremely complex” and “hard to use” I almost can’t believe it. Ayende is a smart guy. So how come he can’t grok Enterprise Library and the simplicity of the tools?

My guess is that this all has to do with familiarity. And every single one of us programmers is guilty of this behavior: we learn the tools we like, and when something else comes along, if it’s not immediately apparent that it is simpler and easier to use (even though it may be) then we dismiss it. And I’m just as guilty of this as Ayende is.

It took me a while to grok exception management and logging using Enterprise Library. For a long time I considered using some other tools, but because I’m stubborn I decided to keep at it until I had it figured out. And at first EntLib did seem complex and hard to use. Then the light bulb went on on my head and I got it. And holy cow, is it ever easy to use. It’s not complex at all; it’s not hard to use. It just has – like many things in life – a learning curve.

At the end of the day this all boils down to productivity. Ayende’s suggestion is often: cobble together your own solution. But why should everyone have to reinvent the wheel? What is wrong with P&P coming along and saying, “Hey, we see this common problem, we’ll provide a solution. You don’t have to use it, but if you don’t want to take the time to build your own, go ahead and use this.”

How many developers need a framework like CAB? Judging from the message boards and downloads, I’d say a lot. Ayende wants to build is own in half a day. Great, he solve his problem, but what about everyone else who still has the same problem? Will Ayende solve all of our problems?

The solutions from P&P may not be perfect. And when they’re not, we are free to choose a different path. But I find it really difficult to fault them for providing solutions that help developers be more productive.

And I find it disturbing that someone as smart and respected as Ayende would stoop to bashing P&P and making claims like, “I can build on the same ideas in half a day and end up with a far more light wieght approach”. That comes off sounding rather ignorant (and insulting), especially to those of us who have grokked the CAB and use it every day.

I guess, more than anything, I’m just jealous of Ayende. I wish I were as smart and fast as he is. Because I know it would take me a lot longer than half a day to build a framework like CAB that had all of the features that CAB has. And that is why we elected to use the CAB; because when my boss asked me how long it would take for me to build a simliar framework, I didn’t say half a day, I said a lot longer. So to be productive we turned to the CAB.

I’m just jealous; I’m too slow and dumb.


  1. Bil Simser says:

    I left a comment on Oren’s blog but I like the points you brought up here. I do have to tell you that it does take a smart developer and a fair amount of time to grok the whole CAB/SCSF/EntLib stack. There’s a lot there. However as I said in my comments on Oren’s blog, you would have to learn the same amount of stuff in any other stack. I kind of see the P&P stuff as the McDonalds of the framework world (if there is such a world). It’s convenient, and it’s all there and you guys keep introducing new things (like IAP). Some work, some don’t. I woudn’t use this stack on any project but for an enterprise app where I want to hit the ground running with features like modularity, logging, AOP, etc. and I have a team that knows it, I think it’s a good place to jump off from. Oren may be able to pump out an injection system in half a day but like you said, does that solve all problems for all people? I’m not saying the injection block does this, but it does the 80% that I need. Oren’s solution probably gives me the 20% that I can’t get from p&p.

  2. Jason Meridth says:

    Good post. Showing the other side is always good. Thank you for the post.

    I don’t think it’s possible for anyone to match his speed. And if they can they don’t blog about it.

    Side note: I hope you have a good webserver, Ayende commented on this post. You’re going to get a lot of visits. :)

  3. Michael Morton says:

    This post would have been a lot better if you would have attacked the points in the original post without attacking the individual on such a condescending level.

    The fact of the matter is, you are both right, in a way.

    First off, the Enterprise Library is heavy, which is not necessarily a bad quality. It can do *a lot* of things in *a lot* of situations, which is a very good thing, but that comes at a cost. The cost is in complexity, both of code and of use. That is what makes it heavy. If the EL does everything you need it to and fits in well with how you *want* to use it, by all means, use it. If it doesn’t, don’t use it, and use something else.

    Secondly, there is nothing wrong with cobbling together a solution so long as that solution provides more benefit than any all-in-one solutions. Since all projects, teams and individuals are different, there is no one absolute solution that is better in all instances. Just because something is all-in-one does not make it inherently better. Nor does being cobbled together.

    Also, just because you cobble together a solution does not mean that you are re-inventing the wheel. You are not building a wheel from scratch, you are building a custom wheel. You are buying the rim from one store and the tire from another. In essence you are deciding exactly what you want and need instead of letting someone else. Neither approach is wrong. If you just want a wheel, just go buy a wheel. If you want a wheel that looks a certain way and handles a certain way, buy the parts that look and do what you want and put them together.

  4. Chris says:


    I agree with your points 100% (all of them, including the first sentence).

    I think what this comes down to is exactly what you said here:

    “If the EL does everything you need it to and fits in well with how you *want* to use it, by all means, use it. If it doesn’t, don’t use it, and use something else.”

    There’s a lot of software, technology and tools I examine to see if they will solve problems for us (and I’m certain this is the case for a lot of us). And often when examining a solution I end up not using it because it is (a) too complex to grok quickly or (b) doesn’t solve the problem as well as another solution or (c) just isn’t easy to use. So I can appreciate Ayende having the same issues with software.

    But what differentiates me from him is that when I run up against software that causes me more pain than good, I don’t run to my blog and post about how bad it is and how many problems I have with it personally. I mainly don’t do that because I know in most cases someone else is probably enjoying success with that software, so it’s me that has the issue and not the software. Instead of ripping said software, I just quietly find something that works instead.

    Ayende took a few shots at the folks from P&P with his post. He’s free to do that, of course. I took it a bit personal though, because the P&P guys, through their software, have made my life more productive and easier and I really appreciate their time and effort. When Ayende ripped the P&P guys I felt like it was a personal shot to any of us who use the software, like saying, “You’re dumb for using that stuff, here’s the way you should do it.”

    Of course that’s NOT what Ayende said; he only complained that HE didn’t like it, and I simply made the mistake of interpreting his comments in a very personal way.

    Anyway, I don’t think there is any “right” or “wrong” here. I think it comes down to “what works best for you.” And on that note, I bet Ayende and I could both agree.

  5. David Hayden says:

    Well said, Chris.

    Enterprise Library and all the software factories from Patterns & Practices are tools to be placed in your toolbox. They are options, not silver bullets. They aren’t intended to be used in all applications and the documentation from Patterns & Practices is very specific about when to use and not use them.

    As you say, CAB and Enterprise Library can be intimidating at first just like any framework when you first start using it. Using EntLib as an example, however, once you spend the time you will find that it is very easy to use and the application blocks are quite consistent in how you use them. After learning one block it is easier to learn others, because you start to recognize the consistency in the configuration and the API’s simple facades and factories. I don’t know how much simpler you can get than Logger.Write, Validation.Validate, ExceptionPolicy.HandleException, etc. for the simplest of scenarios.

    Although not perfect, the tools coming out of Patterns & Practices are definitely worth investigating as they are a good mixture of proven practices and code generation that can make applications better and developers more productive if used appropriately.

  6. Steve says:

    “Would that be an endorsement of Windsor that Microsoft would deem unacceptable? Would it be acceptable for them to build Enterprise Library using Castle Windsor?”

    Oh boy, that would just be aweful wouldn’t it…. let’s build our own everytime.

    Interesting that the same argument against Ayende, is used by the P&P team? ie. build your own, don’t use existing capability that the .net community has created?

    So, the idea is that P&P can’t use what the .net community has built and must roll their own regardless of features because it would an ‘endorsement’.

    That is why it takes so long to build software, they can only use what they build, not what we build?

    I think that is the message Microsoft sends me. As I said in Ayende’s blog, this is MS approach, they did it with MSUnit for example: they want to make everything their own, and rather than use what the community uses, they have to try to ‘outdo’ it, claim it’s better to have a bundle of everything, and meanwhile disassociate themselves from the same developers who are using the framework they build.

    I have a great idea for MS: build the framework, ie. workflow, WPF, and let the community help build the tools – Windsor, Log4Net, NUnit, NHibernate, etc…

    It’s a shame that MS tries to compete against the same people who are using the .net framework to build cool solutions.

    That is part of P&P sir, it’s heavy, it tries to do what others have already done. And it blinds other MS developers into thinking that ‘if it’s not branded by MS then it must not be good’ mentality that MS tries to push at us.

  7. Steve says:

    I’d like to also comment about familiarity.

    We are all guilty of this. Take using an ORM tool. It’s been pushed down my throat since I started developing to use a architecture like DAAB, everything with stored procs, 3 tier setup, etc… until I investigated NHibernate out of curiousity.

    At first, I wasn’t familiar, it took some groking. However , I didn’t let familiarity drive my learning decision. Now, I have a whole new toolset available to me.

    What does this mean for this topic: don’t let ‘branding’ drive your decisions because of ‘familiarity’. In other words, there are API’s and tools outside of the familiar MS logo that work, and work well.

  8. Nicholas Piasecki says:

    I think the following is a reason why developers might dismiss P&P’s tools as “too complex”:

    I’m just a (very) junior developer, and it probably took me about a month to understand the major portions of CAB + SCSF + EntLib. I like to think it’s partly due to the fact that the documentation is embarrassingly poor.

    In fact, I made this work item back in February:

    I really, really think P&P needs to stop whatever it’s doing and put out real documentation for its frameworks. A CHM file doesn’t cut it; they need a book with real samples. I learned CAB not through P&P documentation but by documenting the generated code myself and through several white papers and blogs posted randomly throughout the Internet. If I have to go through that much pain to learn something, then I might as well look at all of the open source projects that P&P competes with because they’re just as terribly documented, too.

  9. John Grace says:


    Excellent comments and much appreciated if people like you didn’t blog and bring balance to the discussion then I am quite sure a few folks would read Ayende’s comments and make the decision not to use the P&P projects.

    Also kudos to Sam


    I have been a big fan of the P&P team ever since the first application blocks were released several years ago. They have saved teams I have worked with countless man days to get projects delivered. Even better is when I do an interview for a hire and ask them have they ever worked with Enterprise Library and they answer yes then I know they have a good chance of hitting the ground running with us.

    To follow up with Nicholas’s point the documentation\samples do need to be ramped up especially with respect to things like hands on labs. Take for instance the WCSF project


    There are still no dedicated hands on labs several months after release (i know there was the workshop, which was excellent but much more is required). I know the documentation is the boring part but trust me it will reduce the barrier to entry for many developers.

    P&P team keep up the good work and remember,

    “You can keep some of the people happy all of the time, or all of the people
    happy some of the time, but you can’t keep all of the people happy, all of
    the time.”

  10. Reusability vs. RYO - Fear and Loathing says:

    [...] Reusability vs. RYO Every so often, a topic brushes by my RSS feeds that I have to jump into and comment on. The latest foray is a conversation between Chris Holmes, Jeremy Miller, and Oren Eini. It started with Oren and a post about not particularly caring for what the Microsoft Patterns & Practices guys are producing (EntLib, CAB, SCSF, etc.) and ballooned here, here, and here. Oren started down the path that CAB (and other components produced by P&P) was overly complex and unnecessary. I’ll focus on CAB but there are other smatterings of things from EntLib here. The main points Oren was getting across (if I read him correctly) was lack of real world applications backing what P&P is producing and overly complex solutions for simple(r) problems. Oren put together his version of the policy injection block (a recent addition to EntLib) in 40 minutes. Last night I was reading Jeremy Millers response and needed to chime in as I’m very passionate about a few things, namely Agile software development and CAB. [...]

  11. Dr. Deall says:

    Excellent comments and much appreciated if people like you didn’t blog and bring balance to the discussion then I am quite sure a few folks would read Ayende’s comments and make the decision not to use the P&P projects.

  12. Capon Luisa says:

    Thank you for the post. And I agre that the tools coming out of P&P are worth investigating as they are a good mixture of proven practices and code generation that can make applications better and developers more productive if used appropriately