On RYO vs. NIH
time to read 7 min | 1362 words

Bil Simser has stepped into the complexity debate with this post.

This is actually on the end of Bil's post, but it deserve a special mention:

As Jeremy put it, the P&P guys are a good thing as they're out there getting the Agile word out to many more people that we can.

In that, I haven't done justice to the P&P team. Introducing Agile methodologies and best practices is something that I am very passionate about, and I failed to give them their due credit about their efforts in this direction.

Oren's defense is around the fact that he (and Jeremy) follow the guideline of evolving a framework from your application needs, not building one (like what the P&P guys have done). Okay, that's fair but at some point you have to stop building things over and over again. So when does your own work become a framework that you reuse?

After you have built one application like this, you can extract the relevant parts into a "framework", although I am not sure that I like the term. The main difference being, again, that this is something that is driven by a developer seeking to make life eaiser, not by BDUF.

The end result is often a purpose fit framework that is very easy to work with, and doesn't require years of study.

Sure, you can put together the basic needs of an IoC in half a day (half a day Bil time, 40 minutes Oren time)

Not really, the basics are deceptively simple, but then you are going to hit a lot of issues with dependencies cycles, life time issues, etc.

I would argue that if you took something like StructureMap and evolved it to handle scenarios that you're not dealing with today, that you would be starting to build your own implementation of EntLib.

Not really, I would tend to use best-of-breed stuff that I would have available, it would cut the stuff that I would need to build by 60% at least. But I would not build the EntLib by any means, I may have components that have similar functionality, but in general, it would be a set of services, not a framework. Jeff Brown had a good post about the difference between the two.

EntLib and CAB do include everything and the kitchen sink and you do need to get past the learning curve, but in the end it's a good collection of tools that you can have in your toolbox.

The first part and last parts of the sentence conflict each other, fairly badly. If they are so complex, I would get much better ROI than rolling my own, or (more likely) reusing stuff already built that isn't so complex.

Unfortunately it's not something I could introduce at a conference or User Group session and describe the entire stack in an hour, so I tend to avoid showing off applications and concepts using it as it just turns into a discussion of what [SmartPart] means instead of the main goal like describing MVP which I can do with my own code.

Don't you think that this is an issue when you can't get the basic concepts of a framework in an hour without drowning in the details? Apples to oranges, but I can show a MonoRail application that has nothing but the basics, and talk about that and the concepts underlying that. If the technology is obstructing the end goal (creating maintianable applications), how is it useful?

Perhaps but then if I choose the 3rd party elements I want and wire them together to suit my needs, what kind of Frankenstein have I built in the progress?

Well, considerring that Frankenstein was a very smart doctor, probably a good one. I think you meant something else, and I am getting tired of answerring that statement, frankly. Using several components together is neither cobbling nor frankenseining nor hobbling a solution, it is using the best attributes of each to achieve a cohesive whole. The end result of a highly componentized architecture is... good design.

I don't think Oren or Jeremy are saying the P&P guys did a bad job on in, they just choose to evolve their own solutions using a minimalist approach.

This is were all the trouble start. I am explicitly not saying that the P&P guys did a bad job, I am saying that I don't believe that the direction they are pushing is the right one.

Like I mentioned with NHibernate, I needed to deploy log4net as it needs it, even if I didn't turn on that feature. At least with EntLib, if I'm not using security for example I don't need to deploy the security module.

Bitchy: Feel free to try to deploy P&P's DAAB without Microsoft.Practices.EnterpriseLibrary.Common, when you are successful, then you can complain that NH has a dependecies.

Seriously, NHibernate.dll has dependencies on several assemblies. And it follows separation of assemblies, so if, for instance, you don't need the 2nd level cache, you don't need the MemCached assemblies deployed.

Eventually I could have a really ugly monster on my hands with copies of Castle, StructureMap, CAB, EntLib, NHibernate, log4net, and who knows what else all living (hopefully) together in happy existence. I don't want that.

You get that with everything that you use, if it bothers you, use ILMerge to make this a single DLL, and then forget about it. Disk space is cheap, and it is really not an issue. About the previous point as well, you can merge log4net into NHibernate if you so like, and get rid of the extra dependency.

Could I get the same functionality from the other alteratives? For sure, however I would probably be writing more code to wire things together than I would with CAB.

I seriously doubt it. A good collection of tools would enable you to write clean, intent expressive code. I don't think that you would end up with more code, if anything, the lack of designer generated code would reduce the amount of code that you would have to deal with.

Tweet Share Share 9 comments
Tags: