Hello, my name is Dmitry Karlovsky, and I am a professional cyclist. In my entire career, I made a bunch of bicycles: large and small, fast and comfortable, curves and straight. Therefore, it’s pretty crazy for me to see intelligent programmers making large and complex applications, but connecting the next leftpad to the project instead of writing a few simple lines with their own hands. All because of the programmers and self-sustaining fear of bicycles in production.

Evolution of the programmer

For simplicity, we select 3 conditional groups of programmers. Conditional, because between them there is no clear boundary, and the same person in different areas can belong to different groups.

Newbie

• He still has little experience and knowledge, but he quickly learns new ones, since he still does not have well-established habits.
• Due to the effect of novelty, he sees well the shortcomings of existing solutions and has a strong desire to make his own, without these shortcomings.
• He does not know how and why certain practices and principles have been formed, and if he does, he has not felt the reasons for their appearance.
• Most of the code written by him is either thrown away or refactored beyond recognition. At best, his own hands under the guidance of more experienced colleagues.
• For writing bicycles it mercilessly beat on his hands, as a third-party library is more likely to be more qualitative according to many criteria.

Specialist

• The overwhelming majority of popular libraries are written specifically for them in their free time, since they still beat their hands on bicycles and on opening source codes.
• As a rule, the quality of its code corresponds to the average quality of the code in the ecosystem. If everyone writes kolbek noodles, then there is nothing left for him.
• As a rule, it uses third-party code, since its own code is not much better, or even worse due to time constraints.
• Respectively, it continues to receive bicycles explicitly (on the code review) or implicitly (by bug-reports) to get hands-on.
• When some problem gets him completely, he cuts a bicycle. And since most of these programmers, it turns out 100,500 incompatible bicycles supported by one and a half developers.

Professional

• Able to solve any of the problems better than the average in the hospital, but due to limited resources I have to choose something to devote time to.
• Out of habit, he is beaten. Especially if the company practices scrum, where all decisions are made by the majority, subject to the effect of Dunning-Kruger.
• Often due to the complexes formed at the first two stages, he limits himself and believes that he is not able to do anything better than an external library that is “tested”, “thought out”, “supported by a large number of developers”.

Causes of fear

Having traced the evolution of a programmer, it is easy to notice that at first he has little skills, but no fear, and as skills are acquired, the fear of bicycles appears and increases. To cope with this fear, you need to make out its causes.

I can not do better

Newbies and the truth can not. He should focus his efforts on explaining the essence and importance of the problems that he sees with his fresh eyes, to more experienced colleagues and library developers.

A specialist will most likely get no worse if he understands the issues well and consults with other professionals and professionals.

A professional is able to do better in most cases, since he is already well versed in the subject and even has the skill of comprehensive analysis. Unfortunately, he usually has no one to consult with, for there are few other professionals, and they deal with other topics. And experts are not enough outlook.

No one will repair defects

Usually the author of the bike is well motivated to repair the defects in his brainchild. But sooner or later this motivation passes, if he does it during off-hours. And here, a third-party library, it would seem, allows you to save resources, because its support is done by other people who don’t have to pay. But it is not possible to influence them, and therefore, in order to have time to deadline, you will have to roll up your sleeves, and repair the defect on your own, and then punch your patch into the main repository for a long time, without any guarantee of success.

There will be nobody to improve and develop

There is the same situation as with defects. But if it is usually clear to all with defects that they need to be repaired, here’s a look at the direction of development is different for everyone. The third-party developer will develop his library where he needs it, not you. With the speed that is convenient to him, not you. So if a specific development vector is required, then your bike gives you control and predictability - two qualities that are much more important for management than time and money costs.

I can't use it anywhere else.

If you want to use a bicycle outside the company, then you will have to develop it either in your free time, or to agree on opening source codes, which is usually more difficult, but quite possible. After all, the company gets PR for free among potential employees, as well as free beta testers (and even contributors, but you should not count on this) in the person of other bicycle users.

Time and money will be wasted.

Here, first of all, it is worth comparing with alternatives. If they are not, then there is no choice - will have to cut. If there are alternatives, then it’s worth comparing in terms of money and time:

• The cost of writing your bike is of good quality. This includes both the actual time of writing the code, the writing of tests, the translation of the project on the bike, and the evaluation of the cost of the defects introduced.
• The benefits that gives the bike. This may be savings due to certain features, a smaller number and cost of defects, and other factors.
• The cost of integrating a third-party solution. Again, including an assessment of the cost of testing and the defects introduced.
• Limitations imposed by third-party solutions. Here it may become clear that a third-party solution does not fit at all. Or that it will slow down the development by 2 times.

It is also worthwhile to separately assess the cost of switching from a third-party solution to a bicycle, if it suddenly turns out that one of the restrictions is no longer acceptable. It often happens that it is more profitable to introduce a third-party solution now, and then quickly transfer it to your bike, when (and if) you need it, than now to waste time on cycling.

This assessment helps both to understand whether the game is worth the candle and to explain to management why they should write their own and not take someone else's (or vice versa).

I will be cursed as I cursed my predecessor

It is doubtful that the bike has a significant share of the project. So they will curse more for the rest of the code. So the bike should be done at least as good. And even better, so that no one has a desire to replace it with a third-party library or with another bicycle. For this you need:

1. The presence of a clear, important for the project benefits.
2. A simple interface to use, so you don’t have to do your wrappers around.
3. Flexible API to not have to cut a new bike with a slight change in requirements.
4. Good test coverage, which allows you to shine less in bug reports and relive refactorings well.
5. Exhaustive documentation, so that you do not need to search for the author of a bicycle in order to understand how to ride it.

I don't want to take responsibility

This is normal if you don't give a damn about the project you are working on. If you do not really care what you devote a third of your time per day, you will have to defend your point of view. And the higher your status, the more responsive it is to approach what you say. After all, your voice depends not only on how you will work, but on how others will work, and where the project as a whole will roll.

Recommendations

I hope I managed to show the baseless fears of bicycles. The closer you are to professionalism, the more ambitious bikes you can take on. It is better to start with smaller bicycles that have fewer risks, but give a lot of experience in this field. And with this portfolio to take on more and more cool and interesting things. It is only important not to forget that a true professional not only does cool things, but also knows when to abandon their creation. Therefore, always carry out an analysis, which will give you confidence that you are doing everything right, and the management will be on your side, and those who come after you will understand what kind of bicycle it is, why it is there, and why it was impossible otherwise.

Well, to help you with the analysis of third-party libraries, I wrote an application for the evening , allowing you to estimate the time for not solving the problems of projects on GitHub . The larger the number, the worse the project with support, and the longer you have to wait for the solution to your problem. For example: a comparison of Angular, VueJS, React and of course $ mol , on which this bike was written. Keep in mind that the last link is one-time, since pumping out all the open problems of Angulyar eats away all the limits of the GitHub, which eloquently shows that his maintenders are not coping with the support of the monster that they spawned.