Argument for the off-the-shelf components

When not to use public components

Public components are not a solution to everything. Let's start by remarking when we should even begin to think about picking a general-purpose solution. The main downside of choosing a public library/ framework/ service is the loss of control. Usually, we don't have any say where the tool should be going, and what the next feature should be. Yes, we can raise our PR but it could be rejected and yes we can fork the project - but usually, we pick a public tool to take off the burden of maintenance, so forking is the opposite of our goal. The other downside is that public tools are built for the general-purpose so they might not be a perfect fit for our specific needs.

Keeping both those things in mind - lack of control and very general purpose of the tools. Where we can't afford those compromises?

In the core domain of our project. The core domain is the main selling point of the system - it is one of the primary reasons why customers will choose us. The core domain is a business driver, not a technical one. We need to keep full control of that aspect of our project, it's the place in code that developers will spend the most time working on. It also should be a part of your system that have the highest quality standards.

Let's take a look at an example: We are building a system for the car rental business. We have to track the fleet, who rents which car, for how long and what's the charge for the service.

The core domain in this example is the whole renting logic. Calculating fees, tracking cars. This is the part that has to be developed completely in-house.

So where are the side domains? Everything else, stuff like:

• charging customer's Credit Card
• any type of report - what is the most popular car, average rental time, etc...
• A GPS to monitor the location of our cars in real-time
• and many more...

I hope with that example it's more clear when we can pursue outsourcing our work and when part of the software has to be custom.

With that aside let's get back to the main topic of this post. Why it's worth considering using off-the-shelf in the supporting domains:

Arguments for the off-the-shelf components

Documentation

No one likes to write documentation and even fewer like to maintain it. Public components usually come with some kind of documentation. Larger projects typically are better documented. But even if the smaller project has an aspiration to make a splash maintainers will know - that good documentation is a must.

If you are a senior developer you might think that you don't need documentation - you can read everything from the code! Altho that may work for you, but you might have less skilled devs in your team and documentation for them could be the only way to learn how the tool will work. So as a senior, picking up a public tool is a excellent way to spare yourself questions "Hey, could you explain me this part of the code that you wrote 3 years ago?"

Community

If you decide to use a public library, you hop on a boat with some other devs. You are not alone anymore. You can start googling for answers, and if the library is popular there is a chance that someone had the same problem before. You can open an issue on Github, and read other issues. Other devs could help you solve your problems or show you other solutions that you didn't think of.

Maintenance

By choosing an actively maintained library, you get its benefits over time. Free improvements, new features and bug fixes to name a few, with minimal effort of just keeping the dependency up to date. It saves time that you could use to bring real value to your customers.

Tip

What if there is not a tool on the market that perfectly fits the business requirements? Then find the next best fit, list out differences and present them to the business. Businesses usually don't know what is possible in the tech space. If you present your argument in a way that: we might save time by getting this tool, but we will need to adjust our requirements. They might agree for a compromise and if they do it's a huge win for the company. A lot of time and money could be saved this way.

If the requirements are strict and we can't change anything about them, we still have some options:

• build the tools that they want from the ground up
• fork one of the public libraries and adjust the code to the specific need of the business (check if the licence will allow you to do, and try to contribute back 🙏)

The latter still saves time. We are missing some of the benefits of just taking code as it is - but at least we could thrive from the colective brain power of previous contributors. I would see implementing something from scratch as a last resort, only if you exhaust other possibilities.