Skip to content
My Docs

Use of third party libraries in software projects

In any software project of considerable complexity, it is often wise to look out for libraries which implement some of the functionality one needs and add such libraries to the project as third party libraries. The main reason for doing this is to avoid reinventing the wheel. It is a sheer wastage of time to write a new piece of software which has already been written, debugged, refactored and optimized a thousand times over by others in the open source community.

There are a few important things which require our attention before settling on any library. This decision is important because in the long run the selected libraries will become part of the project and any carelessness in the selection may bring a lot of frustrations.

In this context, a third party library is any library that implements some common functionality in an abstract way with the intention that it will be reused in other software projects. For example, when one is writing code to interact with a relational database system, one can choose to either use the language provided database wrappers or use an ORM(Object relational Mapper) to interact with the database. In this case, the ORM is the third party library which implements some of the common operations involved when dealing with a relational database system, such as opening and closing connections to the database, transaction management etc.

Some of the reasons which justify the use of such libraries include:

  • We stand on the shoulders of giants by reusing their work. By this we save time, money and shield ourselves from the frustrations of trying to implement and maintain the functionality abstracted by the library.
  • It is also a good way of learning. Some of the famous open source libraries have some of the most well implemented code bases under the universe which have been refined and made better over time. By using their APIs and interacting with their code bases, we expose ourselves to gems of knowledge that can be quite useful in the long run.
  • It is also a good way of contributing to open source libraries. It is usage and benefit which develops interest in a project, and unless we have the interest in a given library, we may not contribute. The benefit of contributing to these projects cannot be overstated. A few lines which fixed a problem which gobbled an hour of your precious time, used by other 300 developers, may end up saving 300 hundred hours. Thats awesome.

In many cases when selecting such a library, there is usually need to chose from among several competing alternatives. We can use several factors to help us in making this selection.

The library of choice should fit the following bill, though it is wise sometimes to make compromises:

  • It should solve the problem it professes to solve, nothing less and nothing more, in a simple and elegant way. If it solves less than it professes to, you may end you being disappointed in the long run, and if it solves more than than it professes to, it may be wise to let go of it, together with the additional baggage it has. A good place to gather this information is usually the library’s README file if it has one, or any other source providing this information.
  • It should be under active maintainance, and the longer it has been out in the wild, the better.
  • It should have a good test coverage. Though the threshold of a good test coverage is a matter more of personal opinion than scientific principle, it is still important to consider this.
  • It should be easy to integrate in your project by exposing a simple and standard API which it is easy to use and straight forward to reason about.
  • Easy to extend or customize, if the need arise.
  • It should be well documented. At a bare minimum it should explain the public API exposed to the user, known issues and common customizations.