What's the name of the antipattern opposite to "reinventing the wheel"? [closed]

Question

The "Reinvent the wheel" antipattern is a pretty common one - instead of using a ready solution, write your own from scratch. Code base grows needlessly, slightly different interfaces that do the same thing but slightly differently abound, time is wasted to write (and debug!) functions that are readily available. We all know this.

But there's something on the opposite end of the spectrum. When instead of writing your own function that's two lines of code, you import a framework/API/library, instantiate it, configure, convert context to datatype as acceptable by the framework, then call that one single function that does exactly what you need, two lines of business logic under a gigabyte of abstraction layers. And then you need to keep the library up to date, manage build dependencies, keep the licenses in sync, and your code of instantiation of it is ten times longer and more complex than if you just "reinvented the wheel".

The reasons may be varied: management strictly opposing "reinvention of the wheel" no matter the cost, someone pushing their favored technology despite marginal overlap with the requirements, a dwindling role of a formerly major module of the system, or expectation of expansion and broader use of the framework, which just never arrives, or just misunderstanding the "weight" a couple of import/include/load instructions carry "behind the scenes".

Is there a common name for this sort of antipattern?

_{(I'm not trying to start a discussion when it's right or wrong, or if it's a real antipattern or anything opinion based, this is a simple straightforward and objective nomenclature question.)}

Edit: the suggested "duplicate" talks about overengineering own code to make it "ready for everything", completely apart from external systems. This thing might in certain cases stem from it, but generally it originates from "aversion to reinventing the wheel" - code reuse at all cost; if a "ready-made" solution to our problem exists, we will use it, no matter how poorly it fits and at what cost it comes. Dogmatically favoring creation of new dependencies over code duplication, with total disregard for costs of integration and maintenance of these dependencies when compared to cost of creation and maintenance of the new code.

Answer 1

No. There is no commonly used anti-pattern name which covers what you are describing.

Answer 2

Golden Hammer

The golden hammer is a tool chosen only because it is fancy. It is neither cost-effective nor efficient at performing the intended task.

source: xkcd 801

(Despite the down-votes, I stand by this answer. It might not exactly be the opposite of re-inventing the wheel semantically, but It fits every example mentioned in the question)

Answer 3

Robert Martin uses the term "Framework Bound" to refer to the most obvious negative consequence of this anti-pattern. As I don't think there's any common name for the pattern itself, a reference to this consequence could suffice for most purposes.

Answer 4

This wikipedia page on "Invented Here" describes a slightly different situation but with very similar end-results. Describes a team's aversion towards creating their own code when equivalent functionality can be found out there.

I would argue that the name is a bit misleading though. Makes sens when put in context with it's opposite Not Invented Here which IMHO is pretty much a synonym for Reinventing the wheel.

Answer 5

I've heard "Buy Versus Build" and "Invented Here" as anti-pattern names for a bias against developing things in-house, even when it may make sense to do so. (And even though the phrase "buy versus build" is supposed to indicate a choice between viable alternatives, I find it is usually mentioned when someone believes "buy" is the correct choice.)

Answer 6

Do not use a cannon to kill a mosquito

Confucius

AKA Overkill

Answer 7

Bloat is a broad term, but it can include what you describe. Our software becomes overly complex (bloated) because of all the extra transformations and abstractions required, and both the complexity and the dependencies themselves contribute to lower performance/less efficiency and higher resource consumption (disk, bandwidth).

If we wish, we could clarify with a term like bloated dependencies.

Answer 8

I think Using a sledgehammer to crack a nut is pretty close. It's something that is possible, but it needs an inordinate amount of work to crack one nut that way, without any of numerous possible undesired side-effects happening. (And there's a whole bag of nuts to crack ...)

The phrase also has the advantage that it is not computing jargon, so it may be very helpful in imparting a clue to somebody who doesn't have any.

By the way, there is a distinction to be drawn with dependency hell. If somebody has already wrapped all the complexities inside an encapsulation which creates simple, clear, easy-to-use interfaces, and provided the penalty in CPU cycles or memory usage is not excessive, and provided future modification of the encapsulated code is unlikely to be needed, then a remaining argument against using it is the dependency hell that it might be causing.

Answer 9

I don't think there is an exact analogue, but I would say that overdesign or overengineering come closest.

At least, I would argue that this is what was really going on when I have encountered something similar to what you describe.

Using a library instead of writing your own code to implement the same functionality is almost never harmful.

Even in your hypothetical example, using a library to replace "two lines of code" may not be necessary, but it's unlikely to cause you much grief--if it is really a library intended to do the same thing as your two lines of code.

A library to do a simple thing will also be simple. It's not likely to give you the headaches that your question implies.

Using a complicated library to do something simple probably implies that you are trying to do more than implement the required functionality.

Such as build in features that are not needed, prepare for a future that may never come, etc.

The problem here is not really failure to reinvent the wheel per se.

Answer 10

If you haven't re-invented the wheel, most likely one is using an existing set of wheels provided by a vendor or 3rd party.

If this is an anti-pattern, then it is usually called vendor lock-in.

Answer 11

Job Security?
You mention all the effort of keeping things in sync, etc. Some people would rather manage other peoples' code than write their own. Managers, especially.