Modern software is built on third-party libraries. It is the most powerful “force multiplier” we have, and the most problematic one.
** Every time we incorporate a third-party library into our system we’re taking on risks:**
- the code could be buggy
- the code could be non-performant
- the code could introduce security holes
But taking on that dependency can save us from writing lots of code. Also, we can’t be experts in everything. It’s frequently better to let others write some code simply because they’re better at it.
We want to build good code that works well and won’t introduce security problems for our users. We don’t have time to write All The Things™, and we don’t have the time and/or expertise to evaluate the source code of the libraries we’re choosing.
Society is built on trust. You’re trusting all your source-not-available stuff all the time.
-Elle Imhoff
I think Elle’s insight is the key to why most developers seem to just look for a library that meets their needs, install it, and move on. We’ve built our society around this concept. We trust that if someone else built and shared a tool that it’s a good one.
I contend that software should be treated differently. Our tools are no longer built primarily by experts. New developers and those lacking experience or expertise regularly distribute useful looking libraries. They can seem to work but be riddled with problems. These time-bombs sit beside libraries from the masters of our trade with no obvious differentiation.
How do we balance this and act as responsible developers?
I think there’s one place where the choice of “do it myself” or “use a library” is easy. If the code you want to use is part of the Standard Library of your language then just use it. To Elle’s point, if you can’t trust your language then there’s no point in doing anything with it.
The suggestion I’ve heard most often is to stick with “popular” libraries. The thinking is that since more people are using it, it’s more likely to not be “bad”.
I contend that this is a bad strategy. Recent events in NPM have shown us that packages can become very popular while being both flawed and pointless.
If we can’t use popularity as a stand-in for trustability then what can we do? There’s no “one thing” you can do, but there is a collection of quick tests we can apply that will help increase your chances.
Look for good documentation
Good documentation is a strong indication of a developer who cares about their code, and users. These developers are more likely to not release code because it “works for me”.
Look for test coverage
There are two aspects to this. A codebase with lots of unit tests obviously has developers that care about quality. At the same time, writing effective tests is a learned skill. So, it may be worth your time to open a random test or two and check that the developers are actually writing meaningful tests.
Even better is a library that has a Continuous Integration widget on their repo that indicates if their tests are currently passing. Sadly, there are many repos out there with tests that don’t actually pass.
Consider Maintenance and Open Issues
It’s a common misconception that lack of recent, maintenance indicates that a library is abandoned, and should be avoided. There are many libraries that don’t get regular updates because they work well, don’t have problems, and don’t need new features. Lack of updates is generally only a concern when there are also reported problems.
Lots of open issues can be concerning. How concerning depends on the responsiveness of the maintainers, and the nature of the library itself. Larger libraries and frameworks with many users frequently have more issues simply because they do more things, and have more people interacting with them. Rails is a good example of this. The maintainers are generally well regarded and major issues get addressed quickly. They make over 25 commits per week, but at the time of writing, they still have over 400 open issues.
On the other side, few or no issues don’t prove a library is good. It could just mean that no-one is using it or looking at it. You can use GitHub Stars, or forks (or similar things on other platforms) as a proxy for public interest or usage.
Putting it all together
Once you’ve decided that it’s worth using a third-party library here are some quick checks to help you choose which one, or if the only one is worth the risk.
- Avoid libraries with lots of issues but no regular maintenance.
- Be wary of libraries with no issues, and no indication of usage.
- Prefer libraries with good documentation.
- Prefer libraries with good test coverage and decent quality tests.
DockYard is a digital product consultancy specializing in user-centered web application design and development. Our collaborative team of product strategists help clients to better understand the people they serve. We use future-forward technology and design thinking to transform those insights into impactful, inclusive, and reliable web experiences. DockYard provides professional services in strategy, user experience, design, and full-stack engineering using Ember.js, React.js, Ruby, and Elixir. From ideation to delivery, we empower ambitious product teams to build for the future.
