To Depend Or Not To Depend

The whole idea of using open source libraries and whether it is even a good idea to include dependencies in our projects at all has been on my mind lately for a variety of reasons. I have been listening a lot to the maintainable podcast and there is a lot of discussion on there about dependencies and open source libraries. I’ve also been having some discussions with both Steve Watts and Chris Cilino. It seems there are really 2 camps when it comes to this idea.

Dependency graph

2 schools of thought

Dependencies are bad

There is a school of thought that says “Dependencies are bad”. They view dependencies as a liability. They can conflict with each other. They can have bugs. They are not always maintained. When they are maintained, sometimes the upgrades break our code (see the 2 line Javascript library that broke the internet). When people download our code they often have to find all the dependencies. Managing all the versions can be a pain. People often include them without fully understanding them. They never seem to do exactly what we want anyway, so why not just write it ourselves or at least fork it and use it as starting point so we are in control.

Don’t Reinvent the Wheel

There is another school of thought, epitomized by GCentral, that says “Don’t reinvent the wheel”. We are all solving similar problems, so let’s figure them out once and be done with it. They view dependencies as an asset. By using a commonly available package they can save a lot of effort. If the packages are well tested, it can also eliminate a lot of risk.

What do you think?

Are dependencies an asset or a liability? If the answer is they can be both, what factors determine that? How do you decide whether to include a particular package or not? How do you mitigate some of the downsides that come with having dependencies?

Updated to Add

I just had an interesting conversation about this recently on Linkedin after pasting a link to this article. Click on the image below to go to the thread on Linkedin.

5 Comments on “To Depend Or Not To Depend

  1. Thanks for posting this Sam. Good discussion on a topic that I’ve been thinking about for years. For many of those years, my general rule was: don’t install 3rd party tools unless you really, really like them and need them. Too much risk with how they may or may not be maintained. (I don’t see much risk in whether or not they actually work as intended. Like any code, when I use one, I have to make sure it does what I want, and if it doesn’t, I fix it or have the original author fix it. Same as if it were my code.) But more recently, as I’ve found third party tools that are really valuable and too complex to duplicate, I’ve eased up on my previous rule.
    Also, I think there is a third case you didn’t mention explicitly. In addition to “they’re bad” and “they’re good”, in my mind there is the case “there’s no way I’m going to write this myself so I’m just going to have to live with it, regardless of whether it’s good or bad”.

  2. My line of thought is exactly what just David said.
    Sometimes you really have to live with it, but I tend to avoid at all costs third party packages, and in last case, I just stick with one version of this third party tool to avoid any code break in the future. And of course, I contribute whenever it is possible.
    I see a great use in the community developed packages, mainly for productivity tools, i.e. Sam’s AF Tester.

    • Glad you enjoyed the article Felipe. The nice thing about the productivity tools is that since they don’t show up in your final code if they tend to cause less problems. I think it is like anything in engineering, you have to weigh the costs and benefits and we may not all come to the same conclusion due to our unique constraints.

  3. A great question Sam.

    From my perspective every dependency carries a risk. What if it doesn’t work? What if I need something else and it is hard to swap out? What if it somehow clashes with something else (especially if it is a piece of the library I don’t need)? What if I forget to install it or can’t find it again on a new machine?

    Good tools and good design can work to minimise these risks. But it does set a minimum bar for the benefit I have to get from the Library. For that reason I tend to minimise my use of basic utility libraries and am very careful to wrap more involved libraries in my own interface in case it needs swapping out in the future.

    Hopefully as good package management improves and becomes more available that bar drops a little bit further.

Leave a Reply

Your email address will not be published. Required fields are marked *