How to pick good dependencies for your code in Production

How to evaluate software dependencies Citing an amazing article by Phil Booth.

7 min readMay 30, 2023

Join 32K+ people and get insights on the most important ideas in AI straight to your inbox through my free newsletter- AI Made Simple

A while back, we wrote about the rise of open source in two articles. We covered two important ideas- why open source beats traditional organizations in development, and how organizations can harness the power of open source in their operations to get ahead. Make sure you check them out to understand this very interesting feature of the tech industry. Open Source is not an avenue you want to ignore. Once you read them, you may be left with one question- how does one pick between the various projects and frameworks to build on top of? This is a fairly tricky question to answer (take a second to think it over).

while over thirty percent of issues are external work-items, they account for more than fifty percent of the overall coordination costs. Moreover, we show that external work-items on average have higher coordination costs than other work-items even after controlling for possible confounds, thus indicating the presence of additional coordination in work-items involving upstream dependencies.

-Source: Is Taking On Dependencies Becoming A Costly Affair?, by Carnegie Mellon. Picking the right dependencies is very important

Luckily, I came across this amazing article answering this very question. In today’s edition of Tech Made Simple, we will be covering how you pick between the various projects to build on top of (PS- The number of Github stars behind a project is not a good evaluation metric). Let’s get right into it.

… understand that starring a project on Github does not signify any specific intention. Some people may use it like an upvote but for others it’s just a reminder system. Mostly Github stars seem to correlate with how aggressively a project has been promoted on social media.
-Social Proof is not a good metric, especially in Tech.

This is another great piece on software dependencies and why it’s important to be careful with them.

How to Evaluate Software Dependencies

What is a Software Dependency- To those of you that aren’t as in with the jargon- A software dependency is a relationship between software components where one component relies on the other to work properly. For example, if a software application uses a library to query a database, the application depends on that library. I got that definition from this article, which is a great guide on dependencies if you’d like to read more.

Step 0: Read the Documentation- This is a commonsense step, but Phil does give a set of great guiding questions you can look at-

Does it solve your problem?
Do you know how to use it?
Is there anything confusing about the instructions?
Is there a changelog or release notes?

This is a great starting point that you can use to evaluate the options. This might be a hot-take, but I personally believe that b and c are extremely overlooked and not given enough respect. If the solution doesn’t meet those two, I would consider reworking the solution to use another tool. As architectures get more complex, we need more simplicity, and relying on structures you don’t understand will not do you any favors. To clarify specifically wrt to b- I don’t mean that you should ditch a framework just because it’s new to you. However, if the structure/design doesn’t click with you (after effort), chances are you will be to do relatively little with it. Consider whether it’s a long-term headache you want to deal with. Also, if you’re someone looking to write better documentation, we have a full guide on it here

Step 1: Read the code

Again something obvious, but hard to do well. Here once again, Phil comes in clutch with a great set of guiding questions-

How clean is it? Is it broken down into functions and/or files in a way that makes sense to you?
Does what you see in the code match what you understood from the docs? Does it adhere to the principle of least astonishment?
Does it contain other dependencies? Are they up to date? What do those other dependencies look like? How deep does the rabbit hole go?
Does it do just the thing that you need, or does it also cater for a bunch of other concerns that don’t match your usage? Do those other concerns impact performance or usability?
Does it receive untrusted input, if so does it prevent that input from being abused?
Can you estimate a ballpark big-O for the implementation? Look for nested loops or inappropriate datatypes that could cause quadratic performance.
Are there tests? How many? Are the tests clean? Can you run them? Do they all pass? How long do they take?
Try to imagine a situation where you have to fork the code and implement something yourself. Does that feel comfortable or scary?

This aligns fairly well with the advice from last section, so I have nothing much to add here. And once again, if you’d like to learn more about clean code, we have two guides on the top- 5 easy tips for clean code and using functional programming principles for better code

Look at project activity-

The next set of questions involves project activity and how it works-

How many unresolved issues are there? How long have they been open? Are any of the unresolved issues concerning?
How many resolved issues are there? How quickly were they closed? How helpful were the maintainers in addressing any issues? Were any issues closed in disagreement with the reporters?
Look at the commit history. Are the original maintainers still involved? If the current maintainers aren’t the original ones, how long have they worked on it? Are they working on the guts of the code, or just touching the edges?
Look at the release history. How often do new releases come out? How often are there breaking API changes? Is the cadence something you’d be comfortable keeping up with?

Out of these, make sure you put appropriate respect on d. The problem with using dependencies is that you are now dependent on someone else’s implementation for activities. Build around a cadence that doesn’t vibe with you, and you sign up for an exhausting relationship with your work.

Step 3: Look at project stats-

In our pieces on Open Source, we talked about the community aspect of open source being a big benefit. Thus, it’s important to look at the community in Tech and see which ones are most important. Here are Phil’s criteria with my comments (in italics)-

How many downstream dependents are there?- More dependents tells you that the devs are less likely to go Elon on their projects to upend their platforms.
How many downloads per day/week?- A good place to do your market research is to see how many downloads something has and why it’s being downloaded. Can help you gain a great perspective on the project.
Are other people successfully using it in prod?- Other’s experiences are great places to learn- this is what this newsletter is based on. Learn from their reports, implementations, and challenges. It’s resources well spent

Step 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 liability or a tax, and a prerequisite to your decision is working out the long-term cost. You must do the research so that cost can be calculated, then weigh it up against the alternatives (and one of those alternatives might be implementing it yourself).

Ultimately, there is too much to keep in touch with in Tech, and doing everything yourself is foolish and impractical. Certain people romanticize “build it from scratch” but things very rarely are from scratch. If you enjoy it, go ahead, but you’re better off putting a lot of effort into understanding and evaluating various tools. Ultimately, a large part of Software Engineering is gluing API/function outputs to other APIs/Functions as input. Learning to work with dependencies is like Casemiro- very useful and underrated.

Photo by Christopher Gower on Unsplash

That is it for this piece. I appreciate your time. As always, if you’re interested in reaching out to me or checking out my other work, links will be at the end of this email/post. If you like my writing, I would really appreciate an anonymous testimonial. You can drop it here. And if you found value in this write-up, I would appreciate you sharing it with more people. It is word-of-mouth referrals like yours that help me grow.

Save the time, energy, and money you would burn by going through all those videos, courses, products, and ‘coaches’ and easily find all your needs met in one place at ‘Tech Made Simple’! Stay ahead of the curve in AI, software engineering, and the tech industry with expert insights, tips, and resources. 20% off for new subscribers by clicking this link. Subscribe now and simplify your tech journey!

Using this discount will drop the prices-

800 INR (10 USD) → 640 INR (8 USD) per Month

8000 INR (100 USD) → 6400INR (80 USD) per year

Get 20% off for 1 year