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.

  • 54
    Dependency hell. That's the closest I can think of.
    – Machado
    Commented Apr 18, 2017 at 15:06
  • 5
    @Machado: Nice, though I'd say Dependency Hell is the direct result of abundance of this anti-pattern; in case of extremely complex systems it may come as a straightforward result of the complexity.
    – SF.
    Commented Apr 18, 2017 at 15:10
  • 29
    I would call it "dependency creep" analog to Feature_creep or Scope_creep where more and more originally unwanted features are added to the product.
    – k3b
    Commented Apr 18, 2017 at 15:26
  • 22
    Tle left-pad fiasco is a real-life example of this syndrome in action.
    – SF.
    Commented Apr 18, 2017 at 18:02
  • 13
    I recommend that we start collectively referring to this as LeftPad.
    – RubberDuck
    Commented Apr 18, 2017 at 22:04

11 Answers 11


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

  • 4
    It appears with the number of ideas, suggestions and discussion it aroused, this is actually correct.
    – SF.
    Commented Apr 19, 2017 at 10:39
  • Huh? "There is no XXX" is a very strong statement and very hard to prove, especially considering there are several candidates mentioned in the comments.
    – AnoE
    Commented Apr 19, 2017 at 17:20
  • 1
    @AnoE "Is there a common name for this sort of antipattern?" The evidence in said comments and answers heavily implies that there is not. True, it doesn't answer the title, but it answers the question itself.
    – Kroltan
    Commented Apr 19, 2017 at 17:27
  • @AnoE You can't prove a negative, hon. Maybe the term is hiding under a rock in Borneo somewhere and we just haven't fallen over it yet? That there are 10 answers instead of 1 with a zillion upvotes is proof enough for me.
    – user251748
    Commented Apr 19, 2017 at 17:30
  • @nocomprende: if it was common, it would have long shown up. None of the presented answers points at this specific anti-pattern, just some of its causes or consequences. You can't prove the name doesn't exist, but this question proves it's not common. (as opposed to the anti-pattern itself, which, despite remaining unnamed seems quite prevalent.)
    – SF.
    Commented Apr 19, 2017 at 17:44

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)

  • 5
    Upvoted, and you can also source it from wikipedia : en.wikipedia.org/wiki/Anti-pattern, en.wikipedia.org/wiki/Law_of_the_instrument Commented Apr 19, 2017 at 9:19
  • 3
    I would downvote this if I had the rep. It doesn't answer the question as a whole, but offers one (accurate) term that answers just one of the suggested scenarios.
    – David
    Commented Apr 19, 2017 at 10:14
  • 3
    The opposite was asked for. This is like insisting that "Becquerel" (radiation, unit is s^-1) can be used for music instead Hertz (hz, unit is s^-1) because they both mean "per second". Commented Apr 19, 2017 at 11:58
  • @ThorbjørnRavnAndersen I have heard some pretty dangerous music in my day.
    – user251748
    Commented Apr 19, 2017 at 17:40

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.

  • 1
    Frameworks exist to speed the development process. They are like a booster rocket: expended as soon as used. The solution is - release version one, now where were we? That's right, developing software. Next! Maintenance is a separate concern, and I think, should be unimportant these days. Take the next framework to the next solution, post haste.
    – user251748
    Commented Apr 19, 2017 at 17:35

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.


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.)


Do not use a cannon to kill a mosquito


AKA Overkill

  • 5
    The common (UK) English phrase is "using a sledgehammer to crack a nut".
    – nigel222
    Commented Apr 19, 2017 at 11:50
  • 3
    Related Monty Python sketch
    – Steadybox
    Commented Apr 19, 2017 at 14:43
  • also: "deer hunting with a tank"
    – Jeutnarg
    Commented Apr 19, 2017 at 15:10
  • "Swatting flies with a hammer"
    – user251748
    Commented Apr 19, 2017 at 15:45
  • Don't use a hammer to kill a fly Commented May 5, 2017 at 11:11

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.


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.


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.


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.

  • 6
    I don't really feel it's the same thing. Vendor lock-in is one particular negative result of depending on a vendor's solution, whether or not the use of the vendor was cost-effective when the choice was made. The OP is more asking about a term for choosing a third-party solution when the integration cost is higher than the cost of simply developing a new solution from scratch (and vendor lock-in is probably not even happening, in the cases where it would be cheap to develop a new solution instead of relying on the vendor).
    – Ben
    Commented Apr 19, 2017 at 1:17
  • @Ben - Ok, I like Framework bound as opposed to vendor lock in better. This question is kind of opinion based and this was the first thing that popped into my head.
    – Jon Raynor
    Commented Apr 19, 2017 at 17:52

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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.