August 5, 2016

What's in a Dependency?

  —Watch your third-party dependencies.

In The Right Thing, James Hague discusses the challenges of selecting good libraries to support your application. In James' example it's a Perl module that turns out to be unmaintained and eventually falls victim to a security issue.

I read James' article a couple of times. On the first read, I took it as a comment on the peril of replacing working code with a third-party library. On the second, I took it as a comment on dependencies and over generalization.

I sympathize with James. He doesn't go into detail on his program but it's hard not to rationalize using a library when one is available. There is the problem of replacing working code with a library.

His comments echo concerns in my own product on the introduction of libraries. The product I work on overuses (some say, abuses) an application framework to the detriment of the product. In response, some team members are suggesting other libraries with simpler APIs but supporting similar functionality.

On the surface, adding libraries is reasonable.

What bothers me is that agreement means I have two libraries with similar functionality but different APIs. There differences introduce costs--additional tests, learning curve, different failures modes and security issues. It introduces the question of which library to use going forward.

There is no easy answer. A good answer requires understanding the trade-offs involved.

• I want a consistent product architecture.
• I want to avoid arbitrary complexity. 
• I need to be pragmatic--the pragmatic demands guidelines. For example, replacing the old library with the new one or using the new one whenever it is sufficient for the task at hand.

The change in perspective provided by the second read was profound. I view James' comments as a warning to evaluate dependencies before accepting them. Caveat emptor, if you will.

So what do you look for in your dependencies?

• actively maintained
• recent release
• good platform support
• good reputation within the community
• active user community
• large user community
• meaningful tests 
• documentation

James provides several links to support his article. In one link I was introduced to Huffmanization. I wasn't aware there was a term for making your most common function names meaningfully short.