#005 Orlando thinks: Choose your libraries wisely

Hello everyone, it’s me, Orlando. I’m an Apple fanboy and software engineer at arconsis. Every week I publish an article from the series “Orlando thinks” in which I highlight a specific topic that I see as important or exciting. Sometimes it might be just certain aspects of everyday life, but sometimes it might be tips, hints, thoughts, or appeals — but non-sense is not excluded either.

This week my thoughts are about a slightly more technical topic again. It is about choosing a 3rd party dependency for your project. When it comes to using a new library in the project, I ask myself a few questions. Only if the answers do not raise concerns, the library finds its way into the project.

Here I want to share these questions.

Do I really need a library?

A very important question to ask yourself at the very beginning. Is a little research perhaps enough to come up with a homegrown solution? Is the problem you’re trying to solve maybe not a problem at all? Sometimes you also tend to WANT to use something — because you can. In private projects or personal playgrounds, that’s ok. However, it should be an alarm signal in larger production projects when you use the new UI framework at only one place where it just replaces 30 lines of code with 5. Often developers tend to use frameworks because they know them but are not aware of a simple solution. My favorite example here is Alamofire. When you only perform one or two network requests — do you need a full-fledged network library? Go with URLSession, and you are fine!

Is that library actively maintained?

Look at the commit history of the framework you are about to integrate. The last commit — is it older than one year? How many people are working on that piece of software? Is there an active community? Do you see some pull requests and discussions around them? These are essential questions when you expect to find help with the API or get feedback on any issues you may experience. In the case of having critical bugs, it feels good to know that release cycles are very short so that you can expect a fast bugfix release.
An orphaned project bears the risk of being left alone with problems, and possible incompatibilities and errors increase with time.

Are there open issues?

If the library is located at GitHub and the “issues”-feature is enabled, you should look at it. Do the open issues give a hint on what problems exist with this piece of code? Do developers maybe experience many crashes? Then you should know why and if it’s worth the risk. Or do you mainly see many suggestions for improvements? Then you should check if this is because the library is not mature or people simply love it and want more features.

Reading the issues and threads provides the feeling of sitting in a bar surrounded by people using the software. By just listening to the conversations, you can get a perfect impression of what state of quality you can expect.

Is the library bulletproof?

If you plan to use a library, it would be good to know if it is already being used in perhaps more prominent and more prestigious projects. In the best case also with an enormous number of users.
Some issues you only notice when you reach a critical number of users.
Do you know companies or other developers who use the framework in production? Do you find stories about it? What is their experience?

If you don’t have any information on this, it would be helpful to check if the project has a comprehensive test suite. This can indicate if the authors of the library try to meet specific quality requirements.

How does the library affect my project?

Imagine integrating the framework into your project. Or better, try doing it on a playground branch. Can you easily compose an interface, so the library is imported in a modular way? Means: Is it hard to wrap it in a way so you can easily remove or replace it in the future? Building an interface also means you can mock the dependency for your unit tests. I highly recommend thinking about these points as early as possible.

Also, how does it affect other parameters in your everyday development tasks? For example, does the build time increase noticeably? Are there conflicts that may arise in combination with other parts of your code? Give it a try before you promote it as the best solution ever, and be aware of the drawbacks.

What about the license?

This is something that is ignored so often. Just because the library is freely available doesn’t mean you can include it without paying attention to anything or that you can include it at all. So, for example, when the framework is under GPLv3, your whole project must be set under GPLv3, too.
This can be very frustrating, especially when you realize that fact after you included the dependency a long time ago.
Be careful — not everything on GitHub is under the MIT license.

By the way, it should always be good practice to list all the libraries used in your product, regardless of whether you have to or not.

Do I understand what happens in code?

I think this is the most crucial question when you integrate “foreign” lines of code.
Using code that other people wrote does not free you from understanding it. Read the docs (if there are any — also a good indicator of code maturity) and understand the logic and architecture. As soon as you debug your own lines, you will quickly come across parts of the library. At this point, you should already be familiar with its structure.

Knowing the framework helps you talk with the authors and enables you to contribute — maybe the one bug you encountered can be fixed by yourself?

Bonus / Fun question: Is it 1.0 already?

It always makes me smile when I see open source projects available for years with a great community and used in thousands of productive apps and projects — but they did not reach the first major release. Breaking API changes are introduced within minor or bugfix releases — but the leading zero in their version is set forever.

Do you want an example? React Native. Initial release: March 2015. Current version: 0.66.3. (Source: Wikipedia)

I always question myself: Why is that? Do they think that their software is not mature enough? Did they set themselves a feature set to which the library will become a stable 1.0 release? And if so: Are the already finished parts mature enough? Why didn’t they go for a smaller set that could be reached way earlier?

Am I the only one who doesn’t get it? :)

Summary

Of course, there are much more questions (also more detailed ones) that one can ask before choosing a 3rd party dependency.

• What about closed source frameworks?
• Does it support my favorite dependency manager?
• Does the library bring in transitive dependencies? (You may also want to go through the questions for them)
• Does it have security issues?
• Do I need to care about data protection and customer consent?
• …

This list depends on your needs. For me, the central point is that you think about these needs and create your own list of questions. Be aware of the trade-offs and drawbacks (there are always drawbacks!) and choose wisely.

Happy coding!

Cheers 🍻
Orlando