Cost vs Benefit of third party software libraries

Recently I have been looking into how to improve the software delivery cycle for new and existing projects.

The first area I want to look at was introducing third party dependencies into software projects. There have been several debates on public forums on whether it is better to use third party components into your solution or not. See Not invented here.

I recall reading that the benefit of third party dependencies is inversely proportional to the amount of effort and longevity of the project (can’t place the reference). One-off / short cycle projects benefit from reusing third party components, whereas long term solutions may not. If you need to deliver a web application to a client in 1 to 2 months, third party libraries will help speed up the release cadence. However, projects that are expected to be delivered over several months and a long obsolescence necessary do not. Consider the recent log4j exploit on several enterprise software.

Often overlooked variables for software dependencies are the learning curve for new engineers and long term maintenance costs. Will that awesome Python or Javascript library be easy for junior engineers to use/debug and will it be maintained in 3+ years? Experience has shown that many engineers like changing projects after 2+ years.

The calculus for introducing software dependencies has become quite complex over the years as well, see Surviving Software Dependencies.

My advice is an obvious one and that is to limit third party library dependencies to well known and battle tested ones only. “A little copying is better than a little dependency.” https://go-proverbs.github.io/

Use external libraries only if your short term goals require a faster cadence, with the expectation that they may need to be factored out to simplify the solution and improve maintainability. Remember your software entropy is a function of the number of lines in your code base including your third-party software libraries and build components.