Judicious dependency selection is a powerful tool
Ah, the blog comment turned rant turned blog post...
Jeff (Coding Horror) applauds Joel's recent article, In-Defense-of-the-Not-Invented-Here-Syndrome, in an article espousing Dependency Avoidance. Not buying it.
Like most things Joel says, if it worked for Excel VBA or FogBugz, it's the way software should be. I disagree. Too many dependencies is bad, but too much custom code is arguably worse, and there's a really sweet spot somewhere in the middle.
How are those custom Excel dialogs doing now? Rewritten to use something standard at some point, I'll bet. Custom code is expensive to maintain, and your only hope for bug fixes and new features is an investment of company time - time could possibly be used in improving the custom code you HAVE to write. Well chosen dependencies are actively maintained and supported, so your product gets better with no additional work. (Of course, good dependencies should have a source code option just in case they stop being maintained and supported.)
I lived horror stories caused by too many dependencies. I've run into just as many problems, though, where developers with the wrong combination of ignorance and hubris reinvented the wheel and came up with a flat tire.
Judicious dependency selection, like estimating and risk management, is one of the hard skills that good developers can wield to great advantage. The "buy or build" decision requires you to honestly evaluate how well your custom widget will look in a few years compared with Widget X's 2008 release. Dependencies should be viewed as expensive tools, but a good team with the right dependencies can concentrate on what it does best and run circles around the "do it yourself" crowd. Software built with carefully selected dependencies can be much greater than the sum of its parts.
Is the Enterprise Library heavy and complex? Sure, if you're writing a simple desktop application. That's why it's called the Enterprise Library - it's a framework for enterprise systems, and in those cases it allows you to build on a framework that's under public scrutiny rather than the product of a few guys at a whiteboard. This thing's been reviewed by some top security experts, for instance - has your framework?
I've been happy with DotNetNuke lately for the same reason. Sure, there's a learning curve, and there are things I'd do differently. However, the system is in use in thousands of production sites worldwide, the product is on version 4.2, and core team had direct contact with Microsoft in coordination with the ASP.NET 2.0 feature set. Does it really make sense to write and maintain your own content management system from scratch at this point?
Joel provides a perfect example of how this kind of thinking goes wrong. In order to avoid a dependency on the .NET framework, his company's flagship product is developed on classic ASP and PHP. In 2006.
 Who picks -1 as the magic number that represents Null? That number occasionally shows up in the real world... Also, I prefer c#, athough I can browse the source in c# with Reflector, so no big deal.
 Yes, I'm aware he does that to support *nix. XSP Mono's ASP.NET does a pretty good job with the *nix's, too, and it doesn't require a custom halfway implemented ASP to PHP converter.