Evaluating Third-Party Libraries

Every platform framework has its rough edges. Whether you’re dealing with Fragments on Android or Auto Layout constraint issues on iOS, you’re bound to run into something you don’t like. I don’t think I’ve ever met a developer who doesn’t have strong opinions on how they could make their framework of choice better. In fact, it would probably make me nervous to meet someone who is completely satisfied with their development infrastructure.

A week doesn’t go by without the announcement of some new library that will take away some of the rough edges that developers dislike. Many people add massive value to the open source community with their contributions. While these contributions are a generally a boon, whether or not they should be included in your project requires careful consideration.

Is a Library a Good Fit

First decide whether you even need to use a third-party library. You won’t be able to answer this question until all of the requirements for the functionality are discovered. Failing to wait for requirements will result in technical debt which can have a lasting impact on the quality and timely delivery of your project.

It’s important to balance the time savings of not having to write the code from scratch against customization and room for expansion. Time savings are often touted as specific reasons that third-party libraries should be used wherever possible. While this is true in many cases, sometimes the savings are overestimated. The amount of code your team will have to write to implement a function is only a fraction of the amount of time a third-party library will save (or possibly cost) your team.

Key questions that help me gauge the impact of including a library are:

• How much time will be spent customizing a third-party library to satisfy all of the requirements for your functionality?
• Does your team plan to expand this function in the future?
• If so, will this library allow room for that expansion?

Which Third-Party Library Should I Use

If you think a third-party library will be a good fit for your use case, it’s time to choose the library.The first thing I determine is which libraries the community is using. There are certainly some excellent projects out there that fly under the radar, but overall, the community is a great indicator of which libraries are good choices.

Libraries that have been around longer have had more time for issues to surface and be resolved. All other things being equal, a more mature project is better than a newer one. However, if a project has been around for a while, it may no longer have an active maintainer. There are widely adopted projects that have since fallen by the wayside in terms of developer support. Maintenance and support will fall on you (and affect your timeline) if the project is no longer maintained elsewhere.

Key considerations for deciding which third-party library to use:

• How many people are (still) using this library?
• How long has this library been around?
• Does the project have an active maintainer? If so, does she engage with the community?
• Does a Google or StackOverflow search yield positive comments and questions with definite answers, or does the community seem to be struggling with this library’s implementation?

Code Evaluation

After evaluating the community’s opinion about various libraries, examine how the code is implemented. The maintainer’s architecture choices can have a deep and lasting impact on your project. If the library requires a lot of boilerplate code or if it replaces large portions of the system framework, it may be costly to move away from the library in the future. How a library integrates with the system framework can have a significant impact on how easily it can migrate to new OS versions.

Pay special attention to the size of the code base. Sometimes large libraries provide extra functionality that isn’t in the project. Additionally, I try to determine whether the library is made up of many smaller components which can be used individually. Some libraries take an all-or-nothing approach that can severely limit flexibility in the application.

One disadvantage of using third-party libraries is the additional learning curve for developers who are unfamiliar with it. Other developers will find it harder to grasp the overall code strategy and architecture for your project if they are spending most of their time in the weeds trying to understand how the library works. If the error messages are ambiguous or if they don’t exist, developers will spend too much time debugging them instead of writing feature code.

Analysis should include:

• If the project needed to move away from this library in the future, how much code would have to be discarded?
• Does this framework rely on undocumented or quickly changing system framework APIs?
• How will this library be affected by OS updates? Does this library try to replace large portions of system framework functionality like Core Data or Android Fragments?
• Are error messages and conditions well documented?
• How difficult is it to set up your development environment for the first time?

Licensing concerns should always be reviewed when choosing a third-party library. Some companies don’t allow certain licenses to be used in projects they own, and some libraries don’t indemnify the project owner or limit liability from its use. With all of the patent litigation that’s happening around the software development landscape, understanding where your company stands on open source licensing is crucial to a project’s success and stability.

One of the best things about modern-day software development is the ease with which we can all share code. But taking some time to plan your library usage in the beginning can save huge headaches and delays later on.