Software is profitable when it abstracts something new
Tags: abstraction, libraries, codingstandards
Published: 2020-10-03 15:51:35

I keep hearing about this JS library which allows you to write one line instead of two for a very specific circumstance. People usually focus on the fact that it broke, but I want to ask, "is it really worth it to install dependencies like this?"

Likewise, if you really *need* [Automapper](https://automapper.org/) because a vanilla method or explicit conversion operators aren't enough, I want to ask if you're using the right architecture.

There's a quote from a Google conference which says something along the lines of, "the world advances when we abstract things." The idea was that we need to install packages instead of building them ourselves. While I agree that maybe you don't need to make your own date picker, I would argue that you shouldn't make something that simply changes the API of your language.

I'm going to use the remainder of this post as a measuring stick for how useful my projects are going to be. I hope it's useful for you as well :)

<sub>*Sidenote: API stands for application programming interface. This term is applied to libraries and frameworks in this post.</sub>

# Installing a new library comes with a cost

We seem to think that installing a free library is free. This is not true. You are relying on someone else's code quality, have to have everyone on the team learn the library, and trust that the code will be maintained for the lifespan of your project. Software with less code has less bugs, but installing a library doesn't reduce the number of lines in your codebase. It just hides code from you. 

# Writing speeds are not the bottleneck.

If we think of ourselves as a disk, our output speeds are way way faster than our input speeds. So using a library to reduce the number of lines of code you have to write is not a valid case. Especially if you're using DRY.

In addition, our input speeds are slow because of the complexity of the code vs the number of lines. Introducing a new library replaces your language's syntax with the syntax for the library. This *can* be good, but only in the circumstance below.

## What you abstract has to be harder to implement and maintain than learning the API.

A good example of this is OpenGL. The API for OpenGL is easier to understand and use than writing my own 3D rendering engine. Likewise, using something like Unity3D is easier than using OpenGL. Another example is an auth library. Even at enterprise scale, it's often better to use someone else's authentication and authorization because writing and maintaining a secure auth model to legal standards is harder than just using someone else's.

True advances in software engineering also fall into this category. Web Assembly is a new technology which offers distinct advantages over JS in specific cases. Containerization and Container Orchestration would be harder to build than to learn someone else's technology. These have specific, obvious use cases and are an obvious improvement over the alternative. 

# Where to go from here
Look at your project and reevaluate your dependencies. What can you *remove* to make a cleaner code base? Is there anything you could be abstracting with a library to make it simpler?