Oftentimes when building software, developers are faced with the decision of “build” versus “buy”. Should I utilize a prepackaged solution for the functionality I’m trying to implement, or should I build my own?
There are plenty of reasons to choose “buy”, the most obvious being that someone else has already done the hard work. However I’ve found that “buy” is usually the default option for most people.
“Why should we re-invent this?”, they ask. It’s a simple (and fair) question that usually drives the most practical choice, but it often misses a certain nuance in some percentage of cases that truly benefit from building.
There’s several advantages to building your own functionality:
Reduce the weight of your application
If you need to support a simple email login, why install the whole devise gem as a dependency? External functionality can pull in hundreds if not thousands of lines of code that add to the weight of your application. Reducing this weight can have great impacts in the long run in terms of binary size, speed of the build, etc..
Control
External software has the disadvantage of being almost entirely outside your control. It’s similar to eating food at a restaurant versus making it yourself – while the former is easier the latter gives you full control of what goes into the food. Perhaps a library abuses the access to your client’s browser window element, for example. Or an Identity service like Auth0 stores your users’ data improperly when you promised them security and anonymity. Ultimately the external software does what you need it to do, but not in the way you’d prefer.
Learning opportunity
Many times building something can be a fantastic learning opportunity. Configuring your own Webpack build instead of using a library like webpacker can be a great way to learn the internals of a complicated system like Webpack. It’s also a big intangible benefit for developers that are itching to learn something new. And having that knowledge in your developers’ minds goes a long way in troubleshooting any issues that come up as well.
Maintenance
Every external dependency comes with the future promise of some maintenance. It can be as simple as upgrading the library version (which itself takes time to update, review, build, and deploy) to upgrading a to a newer API version, or all the way to updating a series of deprecated changes based on the external software’s own decisions. The fewer dependencies you have, the shorter your list of ongoing maintenance tasks and the more likely you are to build software that lasts.
Buy versus build is highly dependent on the context of the application.
While “buy” may be the right answer in several cases, it is important to not blindly default to it. Build is sometimes the correct option as well.