There are many common problems that developers face when writing code. Thankfully, some of them get together and package up common solutions to these problems into libraries or frameworks. A library is a collection of useful utilities and components which generally share a common purpose. A framework is similar, but usually offers some sort of opinionated structure and related magic to facilitate it. For brevity, I’ll refer to both as libraries.
It can sometimes be difficult to decide when to use a library. They are often of great benefit, but sometimes they take more effort than they are worth. Often there are competing options, and it can be hard to know which to use. So here are some tips to keep in mind when making your decision.
Wrong Tool for the Job
Too often developers hear about some popular library and integrate it into their project because it is the new hotness. A few months later, they realize that it is an awkward fit and even gets in the way.
Not understanding your problem or your tool is dangerous. So make sure and spend enough time upfront understanding both. One of the best ways to do this is to interview someone with experience using the library that you are interested in. This can also help you evaluate competing options.
With any tool, it takes time to learn how to use it well. Some libraries come with a steep learning curve, and it can be quicker in the short-term to just roll your own. So you have to consider whether you have the capacity in your current project(s) to make the investment.
Loss of Flexibility
Frameworks are often opinionated, general solutions which may not exactly fit your specific wants or needs. Good frameworks offer a high degree of modularity where you can pick and choose what parts you want. They also expose hooks or configuration options that let you customize them. However, you will sometimes just have to work around the framework to do what you want. If you find yourself fighting with a framework too often, then it might not be a good fit.
So before jumping in, you should decide whether you can live with playing by their rules or not. This starts with differentiating between actual needs and preference. Sometimes sacrificing a preference is worth the benefit, and you might even change your preference.
Many of the more popular libraries tend to be developed and maintained by experts in the library’s domain. They are further refined by being tested in the wide range of applications that the community applies them to. These battle-tested libraries help you quickly achieve a high level of quality that may be painful or improbable to achieve on your own.
The problem with custom code is that only the authors know how to use it. Documentation and examples can help non-authors get up to speed with what the code has to offer and how to use it. Unfortunately, developers tend not to write documentation or at least not write it well. So developers often tend to not make use of existing custom code due to ignorance, bias, or the cost of the learning curve.
Good libraries are well documented, making the right way the easy way. When you use one then it is easier for your team to get on the same page about how to solve problems. It also makes it easier for new hires to hit the ground running, particularly if they have prior experience with the library. Another benefit is that it facilitates learning best practices from the larger development community.
Libraries let you focus on solving the problems that are specific to your project rather than reinventing the wheel. Removing the generic problems from your to-do list means less work. This, in addition to spending less time on bugs and documentation, can substantially increase your development speed.
So there are a lot of benefits to using libraries in an intelligent way. The next time that you encounter a problem that you would consider common, assume that you were born too late to be the first one to run into it. Look for an existing solution and weigh the costs and benefits for your specific situation. Be wary about adopting lots of small solutions like “left-pad” and take time to properly understand larger paradigms like “redux”.
Erik is an agile software developer in Charlotte, NC. He enjoys working full-stack (CSS, JS, C#, SQL) as each layer presents new challenges. His experience involves a variety of applications ranging from developing brochure sites to high-performance streaming applications. He has worked in many domains including military, healthcare, finance, and energy.