Phil Booth

Existing by coincidence, programming deliberately

How to evaluate dependencies

One of my stock interview questions goes: "When picking between dependencies to use in production, what factors contribute to your decision?" I'm surprised by how often I receive an answer along the lines of "Github stars" and not much else. I happen to think Github stars is a terrible metric for selecting production code, so this post sets out my idea of a healthier framework to evaluate dependencies.

0. Read the documentation

The starting point should always be RTFM. The docs will be your guide to using this thing, so make sure you understand them.

1. Read the code

After you've read the docs, the absolute most important thing you can do is read the code. This can be an intimidating prospect, especially if the functionality seems complicated or is outside your normal area of expertise. But even if you're not able to fully grok the entirety of a codebase, there are still many things it's possible to glean by looking at it.

2. Look at project activity

After looking at the docs and code, try to get a sense of activity on the project.

3. Look at project stats

Next try to get a feel for the community around the project.

If you really want to consider Github stars at this point, do so but understand that starring a project on Github does not signify any specific intention. Some people might use it like an upvote but others just use it as a reminder system. Mostly Github stars seem to correlate with how aggressively a project has been promoted on social media.

4. Make a decision

Fundamentally, using a dependency is not a one-off decision that you can subsequently forget about. Dependencies are more like a tax or a liability, and a prerequisite to the decision is working out the long-term cost. Your job is to do the research so that cost can be calculated, then weigh it up against the alternatives (and one of those alternatives could be implementing it yourself).