Choosing a software library or framework

Choosing a library or framework is not like choosing furniture. A systematic approach should support the process.

Luís Soares
Apr 9, 2018 · 8 min read
Image for post
Image for post

I’ll try to abstract from the language/runtime/platform (PHP, Java, .NET, etc.) in use, as the concepts are generic.

Why use libraries and frameworks?

An application of average complexity (e.g. an intranet, an iOS app) can use dozens of libraries and some frameworks. Most are free and many are open source.

Image for post
Image for post

The “problem” is that there are numerous ways to solve the same kind of problem. The web has countless offers. Where to start? How to filter? Sometimes, obvious choices may be dangerous as those may hide people’s prejudices. Be humble to follow a process that removes those prejudices.

Need a new dependency?

  • common algorithms, such as ordering or processing data;
  • import/export from/to a format (Excel, PDF, etc.);
  • creation of a cache;
  • authentication and authorization;
  • animations (graphics effects);
  • serialization and deserialization of XML or JSON;
  • consume or provide a REST API;
  • abstract network communication;
  • multimedia player;
  • security algorithms;
  • template system;
  • mediating objects and tables/relations (ORM);
  • widget toolkit;
  • … among many others.

If you’re only going to take advantage of a tiny part of a library/framework you might not even need to use it. Does the language/runtime bring most of what you need? Do you need only a micro-library/utility and not a giant framework?

Image for post
Image for post
Note: it’s fake

When you decide to include a library you should take into account:

  • the extra resource consumption (network latency, time spent compiling, deploy and runtime, memory costs)
  • the creation of another technological dependency thus having to rethink your software architecture to correctly isolate it;
  • learning time;
  • the inclusion of unknown code;
  • possible incompatibilities with the rest of the software.

When using a framework, in addition to the points mentioned above, you should also consider:

  • some risk of lost time/effort if the choice was poorly made;
  • that programmers may forget or ignore what’s happening “under the hood” (e.g. they may be generating slow queries without knowing);
  • possible impositions (i.e. a framework can impose a way of working and make it difficult not to use it).

In conclusion, it’s okay to add libraries/frameworks to the project if you are aware of the weight of their drawbacks.

How to begin?

It’s imperative that you know very well the problem you want to solve: there are problems with different levels of abstraction (e.g. ordering a list is lower level than creating an online store), so you should match the library level to the problem level. Consider only solutions linked to your development environment (Node.js, Java, Swift); ignore those that have little or nothing to do with the problem to be solved; discard those that do much more than you will use in the medium/long term.

Stack Overflow, Wikipedia and opinion and/or comparative articles are good starting points. Projects hosted on GitHub have the great advantage of giving you metadata (e.g. stars, pull requests, contributors, etc.):

Image for post
Image for post
Metadata analysis of a project

It is likely that you were left with around 6~10 candidates at this stage.

How to filter?

Analyze the mission of the library/framework, its documentation, samples/demos, and its forums/communities. If you can, avoid versions “1.0” (and below); it is likely that they have not yet reached the required maturity. Review software licenses, eliminating those that don’t fit with what you can use in the context of your problem.

Libraries and credible enterprise frameworks or open source foundations (e.g. Google, Facebook, Pivotal, Apache Software Foundation, jQuery Foundation) offer more trust than those made by unknown individuals (but there are exceptions).

After this analysis, you should have reduced the candidates to 2~5. If it’s still confusing or if the choice is decisive for the project (applies more in frameworks than libraries), refer to decision matrices (optionally weighted). Such matrices can help to consolidate/document these studies and present them to decision makers.

Image for post
Image for post
An example of a weighted decision matrix

One way to measure popularity is by using Google Trends. For example, you could check the trends for AngularJS vs Vue.js vs React JS.

In the example of Wikipedia below we see the comparative features of web frameworks for Java (the lines are switched with the columns, compared to the previous table):

Image for post
Image for post

How to decide?

Avoid deciding something based on a whim or curiosity. Run away from empty, emotional or subjective arguments:

  • «I already used it and I loved it»
  • «Facebook uses and it’s spectacular…»
  • “It’s on fire! everyone is using it! »

Focus only on technical and factual arguments:

  • What is the degree of correspondence between the library and the problem to be solved?
  • What is the quality/quantity of documentation?
  • How frequent are the versions (and which was the last)?

It’s time to make experiments (PoC, prototypes or pilots). Focus on implementing one or two key “top-down” functionalities that allow the library/framework to show its strengths and weaknesses. To do it, think about decisive operations in your problem/project. For example: “it’s imperative to have a data table with sorting, filters and inline editing”. What are those features that can’t be missing and without them, the project will fail? These are the ones you want to test in the pre-selected libraries/frameworks.

The effort involved in a decision must be directly proportional to its importance. For smaller libraries, spend less time. For decisive frameworks, spend more. On the other hand, you do not need to apply all of the methods mentioned. Sometimes a good reading of GitHub is enough to feel confident in a pre-filtering or even decision.

The purpose of the PoC is to consider/discard something if it doesn’t fulfill an objective that you consider fundamental; so balance the detail you go into. Each PoC can be done in parallel (by different developers). You could store them in branches in your versioning repository.

Depending on the requirements, consider also comparative performance tests. For example, if you are evaluating a library for JSON parsing, make an exhaustive test battery that allows you to evaluate each under extreme and exceptional conditions (e.g., heavy files, large nodes, etc.). To complement the analysis and help you in the decision, do “A vs. B” type searches (e.g. “volley vs robospice”, “ imageloader vs glide”) and consider opinions from those who have already used the tools.

Finally, choose a PoC as the winner. The chosen PoC codebase can be availed for the project.

Image for post
Image for post


Before deciding to use a library/framework, ask if you really need it, because using it doesn’t bring advantages only. Do a quick cost-benefit analysis: will the disadvantages outweigh the benefits?

In the process of choosing, you should be inspired by the scientific method (in departments that should be R & D, you often forget the value of “R”):

  • The investment of a few days in these experiments can be very rewarding since the wrong choice can have a much greater impact on the project;
  • Don’t label an experiment/PoC as “time lost” if it wasn’t a success; something failing is also valuable knowledge;
  • When arguing, try to bring factual arguments;
  • The fact that tool X has worked well in project Y is not a strong argument (unless projects are very similar);
  • Be humble and assume if you have made a bad choice if any — the sooner you do, the better; whether you have chosen right or wrong, there are lessons to be learned;
  • If you have to make the same choice again, repeat the selection process; libraries/frameworks are born and die sporadically, and the paradigm of the problem is itself evolutionary;
  • Be a “devil’s advocate”: instead of trying to show why the library/framework should be used, try to show why it should not be used — if you can’t, it’s a good indicator.
Image for post
Image for post

Finally, remember that there are no libraries that solve everything or libraries that don’t solve anything. Each problem requires a careful and personalized choice of one or more libraries.

Data Driven Investor

from confusion to clarity not insanity

Sign up for DDIntel

By Data Driven Investor

In each issue we share the best stories from the Data-Driven Investor's expert community. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Thanks to Volodymyr Balytskyy

Luís Soares

Written by

full-stack developer

Data Driven Investor

from confusion to clarity not insanity

Luís Soares

Written by

full-stack developer

Data Driven Investor

from confusion to clarity not insanity

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app