What is the true cost of ownership for third-party libraries?

In application development, the quickest solution to done may not be the best in the long term.

Product engineering is often a trade off between time-to–market and architectural rigor. With the advent of package registries such as NPM, one of the largest developer ecosystems in the world, such third party registries have enabled teams to deliver a faster time-to-market by grabbing a widget from that one and a theme from this one.

However, with the introduction of third party packages, the true cost of ownership increases. The number of lines of code that can break in the software exponentially grows. Sometimes it only breaks in the build or at runtime, but works perfectly fine when developing locally.

“With the introduction of third-party packages, the true cost of ownership increases.”

With front-end engineering, a rule of thumb is that third-party libraries should be minimized if they affect the render. In short, that is anything made for a specific UI framework or render library. One way to filter these libraries is to avoid any package name prefaced with the render library such as “react-.”

Third party libraries that do not affect the render tend to have a more testable surface area made of type-able variables. When things break, you know–and you know why.

When under a deadline, concessions must be made. Time used in the future for updating to a package is technical debt should be called out to the whole team. Nothing in life is ever free. It’s often a trade-off and “that’s a problem for future Homer…man I don’t envy that guy.”

How do you decide what to put in a product testing suite?