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[1]. 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.[2]

[1] 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.

[2] 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.

8 Comments

  • Each dependency means that you have to:



    1) Rely on someone else delivering something when they say they will.

    2) Communicate with someone external.

    3) Negotiate a business relationship with them.



    You should think about how difficult these are likely to be, and compare each dependency individually against the savings from using reusable components.



  • Richard -

    Absolutely. Each dependency is a bet, and a bad bet can be very costly. However, let's look at the 3 problems you've mentioned:

    1. Rely on someone external - Normally the software's in a usable state when it's selected, or it shouldn't be selected. I agree that availablity of source it important so a flaky vendor or open source development team doesn't mean you can't continue to extend the component.



    2. Communicate - Disagree. Why would I need to communicate with someone to use a software component?



    3. Negotiation - Rare. The huge majority of reusable software is downloadable online, either at a set cost or for free. What kind of negotiation are you thinking about?



    I agree with the fundamental assertion you're making, though. Dependencies are costly, and the costs need to be weighed carefully against the cost of doing it yourself.

  • > Judicious dependency selection



    Most developers are good at the "dependency selection" thing but not so good at the "judicious" part.



    But obviously Jon Galloway, and probably most people reading this blog, aren't "most developers".



    The people who really need this guidance most will never read it anyway. But isn't it always that way?

  • Jeff, I am reading this. So buzz off man.

    ;)

  • Perhaps a good blog topic is how to pick your dependencies.



    I've rarely run into project where there were too many dependencies. Nearly all projects I've seen, suffered from the NIH syndrome.

  • Ok, here's a live example for you.

    I'm writing a asp.NET application, and my company seems to be standardizing on using infragistic controls. So after putting together each of my "pages" in a seperate panel, I moved them all into an infragistics tab control. I could easily write something that swaps between divs to make tabs manually, but I figure why re-invent the wheel, right? I mean, infragistics is a pretty well known 3rd-party control vendor, and my company is starting to use them all over.



    So i make 3 tabs, plop in my stuff, figure out this 'creating a reference to the controls that are now child-controls' business, and boom, the datalist on the 3rd tab doesn't work. So i play with it and get help for like 3 days, finally i figure out the problem disappears if i move the tab to the 2nd position. Clearly, an infragistics bug. So i post on the infragistics forums, clean up/simplify my app so i can send it to them as an example, and still no result. No response. No admission of "this is a bug".



    So I guess I'll just call it a wasted week, rip out the infragistics stuff, code my own tab control and move on. The only question is, do i return the whole infragistics package for a $700 refund or keep it in expectation of needing the much-discussed grid control.



    This seemed like an ideal situation to "depend" on a 3rd party control, and it has been a total failure. After this I am going to avoid 3rd party controls unless I am totally unable to afford the time necessary to do it myself.



    By the way, I could've written this app like 500 times over using ColdFusion in the same amount of time I've spend on this bs. But thank god a programmer using a different language can instantiate my dataset class from across the Enterprise. Because that's really helpful when the tabs dont work.



    Ken



  • Ken -

    Sorry to hear that. I feel your pain - I've used and cursed many 3rd party controls over the years. Although it sounds like a contradiction, I generally don't use 3rd party UI controls. I'm much more interested in open source UI controls, so when things go wrong I can crack them open and see why.



    Notice that neither of the examples I gave cost $700 or even $1, and both come with full source.



    And that different language datasets across the enterprise thing is goofy marketing speak that completely undersold the real value proposition of .NET. If that was all .NET had to offer, you'd be right in staying with ColdFusion.

  • Dear Ken. can send you a private email.
    thanks

Comments have been disabled for this content.