Every new developer learns the following core principles of software engineering early in their career:
DRY (Don’t Repeat Yourself)
This acronym encourages developers to avoid code duplication and focus on configurable and reusable components.
KISS (Keep It Simple, Stupid)
Always aim for simplicity in your design by avoiding over-engineered solutions.
YAGNI (You Ain’t Gonna Need It)
Focus on your current requirements, don’t try to predict future needs
But I’d like to focus on a fourth principle, one that pre-dates software engineering:
Don’t reinvent the wheel.
This implies that you should avoid spending time and effort solving problems that others have already solved. As a developer, the most common way of putting this principle into practice is by using third-party libraries.
However, their use is a hotly debated issue (in engineering circles anyway). It’s not uncommon to see skeptical senior developers who refuse to work with them. In this article, we will look at why this is, by evaluating the pros and cons of using third-party libraries. You can then decide which, if any, are a good fit for your app.
Before we dive in, just a quick note: I have written this article with an eye on keeping it language and framework agnostic. Where concrete examples are essential, they are taken from the Android ecosystem, which is the platform I primarily develop for.
Advantages of Third Party Libraries
The most important benefit of using third party libraries is that it saves you time as you do not need to develop the functionality that the library provides. Instead, you can focus on the core business logic of your app: the features that really matter. Sure, you’ll still need to spend some time reading the library’s documentation and understanding how to integrate it, but typically this is just a fraction of the time that would be required to develop and test its functionality from scratch.
Use Pre-Tested Code:
On the subject of testing, another advantage of using a library is ‘proof of use’. A popular library will have been used in multiple environments and use cases. The feedback loop from this will have resulted in bugs being reported and remedied. So, using a proven third party library should not endanger the overall quality and stability of your application.
Use Modular Code:
Another benefit that you get from working with third-party libraries is that it encourages you to work with and write modular code. The library’s code is naturally kept separate from the rest of your application code, and communication takes place across well-defined boundaries (the library’s API). If instead, you opt to develop a feature yourself, it might be hard to decouple it from the app’s code. The authors of a well-built library tend to operate on a different abstraction level, one that leads to a cleaner and more generic code.
Unfortunately, modular code doesn’t always mean decoupled code. Which brings us to the disadvantages of third-party libraries.
Disadvantages of Third Party Libraries
Relying on a third party library means that your code is tied to that library. If at some point, you are forced to switch libraries, your code might have to undergo significant changes in order to adapt it to the new library. There are of course ways to mitigate this by using a facade (wrapper) for the library. This way your code doesn’t directly call the library, but an abstraction instead.
Lack of Support:
Another possible risk is that a library could be abandoned by its author. This is especially problematic in platforms like Android, where new versions come out frequently. A library will need ongoing maintenance to ensure compatibility with the latest SDK version. If that does not happen, the library may not perform optimally (or at all) on newer devices.
Using too many libraries can also cause problems, such as dependency conflicts, which are hard to pinpoint and fix.
An excess number of libraries will bloat your app by increasing its size and memory consumption. In turn, this will detrimentally affect the performance of your app. In the case of Android, it can contribute to reaching the 64k methods limit.
Last but not least, the use of third-party libraries might raise some security concerns as vulnerabilities in open source libraries are increasingly targets for hackers.
So, how do I choose the right library?
While broadly understanding the pros and cons of this ecosystem is important, each library is unique and should be evaluated on its own merits (or lack thereof). To help, I have included the evaluative process I use when doing this. Once you have a candidate library, ask yourself the following questions to see if it suitable for your needs:
How popular is the library?
Many development platforms, like Github, have crowdsourced evaluation built-in. Start by checking how many stars your candidate library has. Then check the number and severity of issues reported for that library. When a significant number of developers trust a library, it’s a good indicator of quality.
Some of the bigger libraries may also have an active community involved in their maintenance and growth. Check Stackoverflow for this, but bear in mind that this is not always directly correlated with quality. Some great niche libraries will have little in the way of a community! An active community is very handy for troubleshooting.
How reliable is the author?
By doing a background check on the author, you minimize the risk of getting stuck with a buggy or abandoned library. Are they active on Github? Have they released multiple libraries? Do they respond to issues, solve bugs and accept pull requests?
If a library is being actively supported by its author, it’s a good sign that it will remain stable, longer term, through platform and frameworks updates.
How well-written is the library?
Briefly go through the code and try to evaluate how well structured it is. Typically, good authors document well. Does it include a comprehensive and up-to-date README file?
A well-documented library will help make integration smooth and effortless. Good code quality will probably mean a stable and performant library, with few bugs.
Does the library meet your specific requirements?
If the library doesn’t cover all your requirements, you might end up having to modify it (more time invested) or using it in a way that it was not intended (for example by employing a hack that might break in a future release of the library).
On the other hand, a library that offers hundreds of features that are superfluous to your needs is probably not a good fit either. Be true to your requirements and keep searching until you find the right library – or worst case, write your own!
Does the library have the correct license?
Another factor that might affect your decision is licensing, as the use of libraries can be limited based on usage. For example, you may find there are restrictions if you intend to release your product commercially. So ensure that you are abiding by the specific terms of each library you have integrated into your app.
Is the library open source?
Without access to the library’s code, you cannot assess its quality or performance, nor can you debug. Not to mention that lack of transparency poses a security risk.
Is the library recommended?
Most platforms have a number of ‘de-facto’ libraries commonly used by the development community. For example, in Android, this would include Retrofit, Butterknife, Picasso/Glide and RxJava. These libraries are high-quality, well-maintained and documented.
While using them is certainly low-risk, do not blindly follow the pack. Instead, do your own research, understand why they are so popular, and check what limitations they have. Just as you would with any other library.
Is this library going to be used for core features?
You should retain full control over the code of your core features. Libraries typically make trade-offs in order to be able to cover a wide spectrum of use-cases. By using libraries for your core features you are making these very same trade-offs.
For example, if image loading is central to your business, existing image loading libraries might not be the best fit. By using one you might compromise on performance, or worse, on features. The library may not be able to work with certain desired image types, or you may want to use a caching mechanism that is not offered by the library.
While the questions above are applicable to most situations, you should always factor in parameters that are specific to your industry or programming platform. For example, if you are working in cryptography, you should be very cautious about writing your own algorithm (unless you have a Ph.D. in the field of course). Crypto is very hard to get right, and the stakes are often very high, so I would advise relying on existing tested libraries.
Hopefully, this article has helped convince you of the use-case for third-party libraries as well providing you with a framework to filter through them: weeding out the unsuitable, unsupported, unreliable and unsafe ones. Each case is unique, so treat it as such, and try to gauge the benefits and potential risks for the particular situation that you are handling.
Don’t listen to the haters. Libraries are not inherently evil and using them does not make you a lazy programmer. When chosen methodically and intelligently they are a great time-saving tool. It’s typically when a thorough and thoughtful evaluation process is not followed that things go wrong.