3 pitfalls of relying on third-party code libraries

What strategy do your developers use when deciding to add a dependency to a project? All too often, there isn’t one. The client requests a new feature, and to minimise the amount of work, the developer reaches for an already-written library which provides the bulk of the required functionality. While their intention might be admirable, they may also be inadvertently creating future headaches for themselves and their client in the cost of maintenance.

You’re assuming liability for code you didn’t write

When you add code to your codebase, you are assuming responsibility for it. When you use a third-party dependency, you’re effectively assuming liability for code you did not write.

Every time you add some code to a project, you’re adding overhead, whether that’s in load time or cognitive complexity. Commonly, when you add a code library that someone else has written, you’re not only adding just the code you actually need to solve the problem, you’re also adding a lot of other code which is unnecessary. Chances are there’s more code in the library than you would need if you wrote only the functionality you need since it has to cope with a broader variety of use cases and is a more generalised solution to the problem at hand. On top of that, the library itself could be just the tip of the iceberg. It likely has its own set of dependencies which also have their own; turtles all the way down! In a nutshell, more code equals more chance of bugs.

Legal compliance

If you’re a developer on a well-functioning team, you should be used to having code reviews of your own and your colleagues’ code. Do you apply this same process to the libraries you’ve used? If not, you should. You’re not doing your job properly if you aren’t auditing code you’re adding. Beyond a code audit, at the very least, you ought to ensure it, and its dependencies, are licenced in accord with your client’s needs. Otherwise, you are potentially opening yourselves or your client up to more legal risk.

The burden of longer-term maintenance

Now, what about when it comes to updates or upgrades? Software doesn’t stand still. Many of the libraries used in Ruby on Rails projects can depend heavily on the framework itself, and thus tie themselves tightly to specific versions. Relying on third-party code means paying attention to it, and diligently evaluating and applying updates. Without constant upkeep, when the decision is made to make major upgrades, there is often a lot of unknowable work in updating the dependencies to find versions that work. You may need to make significant changes to your application to work with the updated version. Worse, you may find that the library chosen is no longer maintained for the newer framework version. Then you have a decision to make, take on the maintenance of the library yourself, or rip it out and find (or write) an alternative solution to re-implement into the codebase. All of which takes time and costs money. The short-term saving in initial development is beginning to look questionable.

More eyes tends to mean better quality

On the flip side, there are definitely times where using a third party code dependency absolutely makes sense.

In open source software, popular libraries do have the benefit that more eyes have probably seen and worked on the code, so there is a better chance of quality, where fixes and bugs have been contributed back having been tested in other production environments.

For important, critical functions such as encryption, it’s far better to defer to people who have considerable expertise in the matter. After all, we can’t be experts in everything.

Do your due diligence, decide intelligently

Code reuse makes sense, there’s no need to reinvent every wheel, however choosing a code library should be a thoughtful, active process. Don’t only reach for the nearest library out of laziness or speed of development. I’m not saying you shouldn’t use libraries, but you must do your due diligence. Trust, but verify. Remember, you’re assuming liability for code you did not write.

In frameworks like Ruby on Rails, which makes rapid development possible, it’s often better to write what you need to suit the needs of the project without excess code. No code is better than some code. Your future selves will thank you for it.