Write code from scratch or use an existing library?

Have you ever faced the problem of choice: use an existing library or write the code yourself? I never understood this question and always gave preference to the ready-made solution. However, recently this dilemma arose again at work, we argued a bit, as always, but this time, when making a decision, I still had doubts. About pluses and minuses of each approach read under a cat.

Speed ​​and quality of development

There is no doubt that taking the already existing library, the development of the basic functionality will be completed much faster. The developer will focus on exactly the functionality, not the infrastructure, etc.

The optimal solution

Libraries are usually written quite universally with an eye to solving many different problems. Therefore, their code is rather cumbersome to understand and is hardly the most optimal for solving your particular problem. In the case of your own decision, you write it in the most optimal way and you will sharpen it specifically for your particular use case.

Bugs

In the case of the library, you have a solution tested by many users. If you still find an error, it is enough to enter the text of the message in Google, and you will immediately understand what you are doing wrong. On the other hand, if no one has come across this error, or it’s just so obvious that nobody writes about it, then you can spend a lot of time to figure out why something isn’t working. After all, the library code can be quite cumbersome and confusing. Here is an excellent example of how such a library can turn out. Moreover, it was not you who wrote it, so it will take a long time to understand another's code, and for this you need a special skill. It is good if the library is open source, otherwise communication with support may further lengthen the search for errors. If you wrote all the code yourself, then you know it far and wide, and finding the error there will be easier than ever. Here are the errors, there will most likely be much more, since only you have tested this code. Even if you are writing code from scratch, then there is a chance that you will lose sight of some rare case that the library has already been identified and encoded with time.
')

Team

There are two aspects to it. First, when a new person comes to your team, it is likely that he has already worked with the technology that you are using as a library (or you immediately hire a person with the condition that he has relevant experience). If you use your own solution, then the new employee will have to understand the details of how it works. Secondly, writing the code itself, which is usually written in libraries, is not an easy task. Here you need a highly qualified specialist, or all the other advantages of your own solution will come to naught if the code is written by the pioneer.

To summarize the pros and cons of each approach:

Library

• + Quick development
• + Code tested by a huge number of users
• + People coming to the team know how it works
• + Solves problems that you might not have foreseen, implement the library yourself.
• + Programmer concentrates on functionality, not on auxiliary library.
• - A lot of classes, a rather complicated overall architecture, so it’s hard to understand the errors that occur
• - Maybe not doing some very specific thing that would be very useful to you for your specific task, so you use a slightly different thing
• - It can not solve your specific problem in the most optimal way, because it contains a bunch of wrappers and flags for other tasks inside
• - When self-patching the library, problems may arise with a future version upgrade.

Own development

• + Team members know how everything works in detail (until they leave the team)
• + It is easy to determine the cause of the error, since the written code is minimal
• + Maximum performance solution
• + Ability to develop the library in the direction you need
• - Requires a highly qualified developer to write a good library
• - Long development
• - Contains a sufficient number of errors, especially at the stage of implementation
• - New people in the team do not know how it works

Your comments are very welcome. It would be interesting to hear what else you need to pay attention to when making a decision.