Is the counselor competent? Problems recommending "don't reinvent the wheel"

Quite often it is necessary to meet the recommendation "do not reinvent the bicycle". Sometimes with pronounced disdain and self-assertion, sometimes, ostensibly , as practical advice. However, even if it is intended to be a council given out of good intentions, in a number of contexts it only shows the speaker’s incompetence.

The inserted purpose of the phrase is to protect against the performance of useless work, the call to use a ready-made solution for the task, and from the point of view of an outside observer, it really looks reasonable.

But at the same time, the key factor , which is characteristic not only for the development of software, but also the solution of any tasks , is overlooked : when the context in which the task is given changes, the solution also changes .

To lose sight of this principle is the same as admitting one’s own inability to solve applied problems.

Consider a few cases.

A source

API over API

One of the most common cases of accusations in cycling is the independent writing of the API wrapper of a service, the implementation of which already exists.

A case from my practice.

It was necessary to implement the data download from Facebook to our service. Mainstream language and library from Facebook itself googled in 2 minutes.

The library documentation did not correspond to the current program interface , a lot of unnecessary actions were wrapped around each manipulation. The library was of very poor quality .

Result: after 1.5 hours of work with it, it was not possible even to log in.

A colleague implemented his own Facebook web-api wrapper. In total, it took about an hour to create wrappers and related functionality on the service side. To the question "why are you riding a bike," he answered the next few days.

This is especially pronounced in mainstream language with a large community: there is an unhealthy tendency to publish API wrappers over another API, under the slogan "For humans" and "In simple way". Such wrappers become obsolete as soon as the interface being wrapped is updated, and the authors throw such "projects", making the code that uses them non-working.

Common question : and what, to write such wrappers manually every time?

Answer: A much stronger solution for large wrappers will be the use of a code generator interpreting specifications.

Control over the code base and failure to answer for other people's errors

In the circles of wannabe development of computer games such a phrase is addressed to anyone who dares to implement their engine. "Why reinvent the wheel? Take a unit!" . Or Game Maker, or, no, God forbid, Defold.

It would seem that dviglo \ designer provides all the necessary tools for development. Many of them are cross-platform and generally simplify life.

How should the context change here to make it necessary to make your own engine?
At a minimum, this control over the code base and functions of the engine (for example, on some models of controllers, the game maker is consistently buggy, and it can be very difficult to fix). That is, it is necessary to reduce the likelihood of meeting an “alien bug” , which cannot be corrected independently or is extremely difficult.

This is especially pronounced in games that are not saturated with graphic and / or physical bells and whistles - trite, not so much the conventional engine takes on itself.

In addition, there is no need to increase the total amount of the code base if a small part of its functions are used from the engine / constructor, and you still need to add the necessary tools yourself , simultaneously controlling the correctness of their work with the engine.

For example, based on such assumptions, Tommy Refenes wrote his own engine for Super Meat Boy .

Someone will object: "But after all, in the store \ some other storage, there is a mountain of presets \ tools \ extensions!" .

Yes, it is wonderful, and gives a couple of points ahead, but in engines with a large active user base, the same effect is completely "die young", described in the previous section. Without context and a specific task, one cannot unequivocally argue that, de, an abundance of user extensions in the stack will play into the hands.

Imaginary identity. Pulling the task by the ears.

Sometimes, having formulated a task, it turns out that existing solutions that come to mind ... are not suitable. Because of its "fatness" or dissatisfaction with one of the key conditions of the problem ( yes, there are several of them ).

A good example: CluNet.

Cluster in his article sufficiently described the reasons for the decisions taken by him in the development of the smart home protocol. The example is very illustrative and well described, I recommend disassembling it yourself.

Conclusion

When searching for a solution to a problem , the context and all specified conditions are necessarily considered .

Even in simple cases, small details of the context turn the solution upside down, and the skill of solving applied problems is largely based on the ability to see and evaluate the initial premises .
So does the phrase “don't reinvent the wheel” say about the inability of an adviser to solve problems? If the adviser mentioned bicycles earlier than a few minutes of thinking, most likely, yes.

Or, summarizing:

Before you decide - think.
Before you speak - think.
And in general - think.