Picking a library or framework can be a risky decision. Pick the wrong one and it can end up driving much of the architecture of your system. Frameworks are especially notorious for this because, by their nature, they dictate the structure and conceptual underpinning of your architecture. Picking the wrong one and then seeking to change it can be a considerable effort; one that involves changes to almost every single piece of code within an application. As such, it is vital to practice the skill of careful consideration and selection of third-party code:

There are a number of useful considerations we can make in order to help us in the process of selection:

• Functionality: The library or framework must fulfill a set of fixed functional expectations. It's important to specify these in a sufficiently detailed way so that different options can be quantifiably compared.
• Compatibility: The library or framework must be mostly compatible with the way the code base currently works, and must be able to integrate in a way that it is technically simple and easy to understand for colleagues.
• Usability: The library or framework must be easily usable and understandable. It should have good documentation and a level of intuitiveness that allows immediate productivity without pain or confusion. The consideration of what occurs when you have a problem or question related to usage is also under the umbrella of usability.
• Maintenance and security: The library or framework should be maintained and have a clear and trusted process for reporting and resolving bugs, especially those that may have security ramifications. The changelogs should be exhaustive. 

Even using these four criteria, however, we may fall into traps. If you'll recall, in Chapter 3, The Enemies of Clean Code, we discussed the most notable Self (or ego) and The cargo cult. These are also relevant when selecting third-party code. Remember to specifically watch out for the following:

• Powerful opinions: It's crucial to separate ourselves from the decision process as much as possible, and to be very wary of our ignorances and biases. Programmers are well known for their opinionated nature. It's important in these moments to step back from ourselves and reason with pure logic about what we believe would be best. It's key to give everyone a voice as well, and to weigh people's opinions and anecdotes according to their own merits, not according to their seniority (or other personal characteristics).
• The popularity cult: Don't get too swayed by popularity. It's easy to get drawn into a popular abstraction due to the size and zealotry of its community, but once again, it is vital to take a step back and consider the merits of the framework in isolation. Naturally, popularity may indicate an ease of integration and more abundant learning resources, so in that way, it is reasonable to talk about, but just be wary of using popularity as a sole indicator of superiority.
• Analysis paralysis: There are a lot of choices out there, so it is possible to end up in a situation where you are seemingly unable to make a choice out of fear of making the wrong one. Most of the time, these decisions are reversible, so it's not the end of the world to make a less than optimal choice. It's easy to end up in a situation where a lot of time is being used up deciding which framework or library to pick when it would be far more efficient to just pick anything and then iterate or pivot according to changing needs at a later point.

The key thing when making decisions about third-party libraries is to fully appreciate their eventual effects on the code base. The amount of time we sink into making a decision should be proportional to their potential effects. Deciding on a client-side framework for component rendering may be a rather impactful choice as it may prescribe a significant portion of the code base, whereas, for example, a small URL-parsing utility does not have a great impact and can be easily swapped out in the future. 

Next, we can discuss how we might integrate and encapsulate a piece of third-party code, following a well-informed selection process.