Library-Driven Development

Everyone uses libraries. They are your optional way to save time on writing boilerplate code. But when to use them is a debatable question.

The unspoken rule is: keep writing custom code until you get the feeling that something is so common that there must be a standard way of doing it.

But there are those who disagree: those who vowed to write everything from scratch and those who never write a line of code without checking GitHub for a ready solution.

The Wheel Already Exists

The benefits of somebody else solving your problem for you seem reasonably obvious. Apparently though, considering how many developers are religiously set on implementing everything themselves, they’re not obvious enough.

1. Reuse

Having to implement a feature once means that it could happen again. After spending enough time developing for the same platform, you start running into the same problems over and over again.

Plain and simple benefit of using libraries is being able to include the same solution in every project that needs it. One-line change in your build script (provided you have dependency management) is clearly better than manually importing utilities from your past projects.

2. Maintenance

Once you’ve manually implemented a utility in your application, it’s unlikely that you’ll ever revisit it unless it causes a bug or breaks a test. It’s there, it works. Forget about it.

The problem is that the only input your utility will ever receive is from your application. Hence, any use case that you missed and any external dependency that has changed will remain undiscovered until a user performs a sequence of actions to uncover it.

A well-maintained library, on the other hand, will receive feedback from dozens of developers who ran into the same problem, likely resulting in a fix before you even notice the bug.

3. Know-How

It’s often assumed that given the same amount of time and testing, everyone will arrive at a result of a similar quality. That’s completely false.

Somebody who knows more about the platform and is more experienced can produce a solution that’s better than what you would have written yourself. Your developer ego shouldn’t prevent you from accepting this fact.

Your Wheel May Vary

Now that everyone is hopefully convinced that libraries are necessary, we need to set some boundaries. Not everything needs to be outsourced to a library; you’re still the developer of your project.

1. They’re Not All Good

Not all libraries are good. In fact, some are terrible. Remember that anyone can publish an open-source project, they don’t have to be knowledgeable or experienced.

This can invalidate the know-how argument from the previous section, so review their code before trusting it. It’s entirely possible that your solution is better or more complete.

Don’t assume that the maintenance argument is always true either, not all open-source projects are actively developed and maintained. But even if they aren’t, they can still be useful, you’ll just have to test and fix everything yourself.

So what if there are no good libraries solving your problem? Don’t use any! Write your own code and consider publishing it for the next person facing the same challenge.

A colleague of mine has written a handy guide to choosing third-party frameworks, which can help you sort out the decent libraries from the disastrous ones.

2. Take What You Need

Think about the scale of your task. Now think about the size of the library that you’re considering. If all you need is one method from a massive framework, then it may be an overkill.

One option is to import that method manually (provided the license allows it), but be careful not to import too much. If the implementation implies future changes, manual imports will be a nightmare to update.

Always keep performance in mind! Depending on your language and platform, adding more libraries can result in slower builds and larger distribution files.

There is no universal solution for this, but things like ProGuard in the Java world can help optimise your libraries by removing parts of them that your application is not referencing.

When optimisation tools are unavailable or ineffective, consider getting rid of non-essential libraries or finding more compact alternatives for them.

Conclusion

There are no tenable excuses to avoid libraries altogether, they bring undeniable benefits and are generally a good idea.

By the same token, your application shouldn’t turn into a collection of libraries where the only code you write consists of bridges between them.

When you decide to use a library, don’t blindly trust other people’s code and take the time to review it.

Originally published at blog.gouline.net on September 26, 2015.