104

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.

SF.
  • 5,078
  • 2
  • 24
  • 36
  • Could the close-voter explain how the name is is opinion-based? – SF. Apr 18 '17 at 14:58
  • I don't know of any name for that, I propose: "Mountain of APIs" – FrustratedWithFormsDesigner Apr 18 '17 at 15:04
  • @eidsonator: That's the basis for "reinventing the wheel". I'm asking the exact opposite: Use anything "not invented here" no matter how barely applicable, heavyweight or unnecessary; example may be using coffeescript to create a trivial redirect page on a deactivated webserver that doesn't serve anything except redirects to the new site. – SF. Apr 18 '17 at 15:04
  • 54
    [Dependency hell](https://en.wikipedia.org/wiki/Dependency_hell). That's the closest I can think of. – Machado Apr 18 '17 at 15:06
  • 1
    @Machado: That one can sometimes happen with only a small handful of dependencies, as long as they are sort-of mutually exclusive depending on the versions. I think OP wants to name the situation where there is a *great big heap* of external libraries and dependencies that must be imported just to get things to compile. – FrustratedWithFormsDesigner Apr 18 '17 at 15:09
  • 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. Apr 18 '17 at 15:10
  • @FrustratedWithFormsDesigner: I'm actually asking for the name of a single building block creating such a situation. Working in embedded, you really don't need much to hit the limit. Import Boost, and you're out of half of available RAM already, no matter how tiny a task Boost helps you at. – SF. Apr 18 '17 at 15:12
  • 5
    @SF.: How about "Iceberg dependencies" because it *looks* small on the surface "Oh, I'll just import Spring Boost" but then it pulls in a whole bunch of other stuff "under the covers" ...? – FrustratedWithFormsDesigner Apr 18 '17 at 15:19
  • 29
    I would call it **"dependency creep"** analog to [Feature_creep](https://en.wikipedia.org/wiki/Feature_creep) or [Scope_creep](https://en.wikipedia.org/wiki/Scope_creep) where more and more originally unwanted features are added to the product. – k3b Apr 18 '17 at 15:26
  • 1
    In Polish there's an idiom that is applied to this situation in general, not just in software, the translation would be "going with a howitzer against sparrows". A less frequently used one is "sharpening pencils on millstones." – SF. Apr 18 '17 at 15:33
  • @SF.: Hmm I think that expression would apply to situations where an application is built using Spring Boot, but could have been built in a much simpler way without it. I *thought* you were looking for a name for the situation where you actually *need* Spring Boot, and are bothered by how much other stuff Spring Boot brings with it, but which you can't dump because your dependency depends on many other things. – FrustratedWithFormsDesigner Apr 18 '17 at 15:42
  • 2
    I don't know of any accepted name but I would go with "Never use a cannon to kill a fly" that somewhere is reported to be a Cunfucius' quote. – danidemi Apr 18 '17 at 16:12
  • 1
    @danidemi: I've heard (and also used) the phrase "Hunting squirrels with artillery". ;) – FrustratedWithFormsDesigner Apr 18 '17 at 17:41
  • 22
    Tle [left-pad fiasco](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) is a real-life example of this syndrome in action. – SF. Apr 18 '17 at 18:02
  • 3
    Possible duplicate of [Is there a term for over-complication of OOP?](https://softwareengineering.stackexchange.com/questions/343465/is-there-a-term-for-over-complication-of-oop). The term you are loooking for is overengineering. – Doc Brown Apr 18 '17 at 20:10
  • "Fear of change" might be a reasonable name for it. – Cort Ammon Apr 18 '17 at 20:56
  • 13
    I recommend that we start collectively referring to this as LeftPad. – RubberDuck Apr 18 '17 at 22:04
  • 1
    @SF. LeftPad is not an example of the complexity you describe. Sure, it adds a very small piece of functionality that could be duplicated easily, but left-pad didn't add a lot of complexity to projects that used it. On the contrary, the library provides a simple piece of functionality and has a simple interface. The problem was that *a lot of projects depended on it when it was removed*. (In an ideal world, the incident would motivate including the functionality in JavaScript's core API.) You describe depending on a bloated API that creates more complexity than implementing it yourself would. – jpmc26 Apr 18 '17 at 22:30
  • @jpmc26: I agree left-pad isn't that great of an example - because it was usually one of hundreds of modules included through npm, and while the whole solution (npm repository system) is big and heavyweight, the benefit of the broad range of modules was well worth it. Imagine though including npm in your project _only_ because you need left-pad, and nothing else from its repositories. Would you say it's justified? – SF. Apr 18 '17 at 23:09
  • 1
    @SF. In the case of npm, not really. npm is part of standard Node and is the standard package distribution mechanism. If you expect your project to be of any size, even eventually, it's normal and fine to go ahead and set up the standard structure as a default. (Who wants to reorganize the whole project later just because you didn't want to follow standards? May as well just set it up that way as a matter of course.) And then you have the choice of including a simple library or writing your own left pad. It's not like pulling in Mustache to generate a 50 character string with one variable. – jpmc26 Apr 18 '17 at 23:24
  • 1
    What you described is not an anti pattern. It is a best practice. – emory Apr 19 '17 at 01:34
  • 2
    @emory Wasting time and money to create a subpar solution on top of a platform that doesn't do a good job of solving your actual problem and probably has massive licensing costs is a best practice? I guarantee that happens. – jpmc26 Apr 19 '17 at 02:55
  • @jpmc26: now imagine writing pages that don't interact with the server; a web1.0 site with no cgi scripting and only minimal javascript for some navigation etc. And using node.js + npm to include left-pad because you want to indent the nav menu with  's. :) – SF. Apr 19 '17 at 06:34
  • 1
    @jpmc26 Without wanting to get into a general argument over roll-your-own vs. library-reuse, I'd say an overly-dogmatic adherence to either is probably "not good". And LeftPad seems a pretty good example of when "_there's a library for that_" can be taken too far. IIRC, there is/was little more than one or two lines of actual code (in 10-20 lines total?) – TripeHound Apr 19 '17 at 12:02
  • > *When instead of writing your own function that's two lines of code, you import a framework/API/library* Javascript – Manu343726 Apr 19 '17 at 12:25
  • @SF Something has to serve those pages, node.js does just fine as a static server too (with minimal setup, at that). Of course, this assumes you already use node.js for other projects, installing it just to use as a static server and nothing else is indeed a bit much. – JAB Apr 19 '17 at 14:31
  • @TripeHound: I'd say that if a significant fraction of the users of a language use a function to perform the *exact same action*, that's a pretty good sign that a standard library function for that purpose should be part of the language spec. If it would only be meaningful on some kinds of implementations, it could be made optional for implementations where it might not be meaningful, but having it in a language would be better than having everyone implement it separately or create otherwise-needless dependencies on a third-party utility. – supercat Apr 19 '17 at 16:21
  • 1
    @supercat Fully agree that having a common function (in this case left-pad) part of the language would have been better (though adding it now would give version-check problems). Having it as part of a larger utility package would be better (it's probably in several). It just struck me as almost comical that the "package that broke the internet" was essentially one line of code. – TripeHound Apr 19 '17 at 16:30
  • @TripeHound: I find it irksome that the C Standard Library includes silly things like `strncat`, but no standard way to take an [aligned/not-necessarily-aligned] pointer to [2/4/8] chars (used for holding octets) and [load/store] them as an integer type in [big/little]-endian order. Combining all options would yield a fair but not unmanageable number of functions (24), and for compilers to define intrinsics that would give optimal results on each platform would seem easier than trying to recognize and generate optimal machine code for all the ways the tasks might be done in portable C code. – supercat Apr 19 '17 at 16:44
  • @TripeHound: Note that the usefulness of such functions would not be limited to machines with octet-based storage; to the contrary, they'd ease porting of code that operates on octet-based data to machines that use non-octet storage. While it would be easy for anyone to write such a group of functions (and I have), the only way to avoid either having everyone write their own or the creation of what should be needless dependencies on an outside library for that purpose would be for the language to build such a thing into the language. – supercat Apr 19 '17 at 16:49
  • 2
    I call it "Import the World". As in, "stop trying to import the world!" – user3067860 Apr 19 '17 at 17:23
  • @user3067860 "Stop the world, I want to get off!" –  Apr 19 '17 at 17:28
  • @TripeHound No dogmatism here. If you have a good reason not to set up your project to enable npm package installation, go for it. What I am saying is that it's a reasonable default. [left-pad](https://www.npmjs.com/package/left-pad) is currently 52 lines. See the github repo. – jpmc26 Apr 19 '17 at 19:15
  • @jpmc26 I'm all for using npm, it's just using a package for essentially one-line of code that seems to be taking things too far. – TripeHound Apr 19 '17 at 19:22
  • @TripeHound Except that I'm saying I would set up the project that way by default even if I needed no packages at the start. Someone may want to add minification, testing, grunt, or other tooling; that's a reasonable expectation of the future. It's a reasonable default to save trouble later. If having done that as your default, you decide to pull in left-pad to save yourself writing the code, I don't mind. If you could guarantee that you would never need to pull in other packages, yes, you could argue it's overkill. That is so difficult to guarantee that I would be skeptical of the claim. – jpmc26 Apr 19 '17 at 19:26

11 Answers11

49

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)

Community
  • 1
martin
  • 363
  • 1
  • 2
  • 6
  • 5
    Upvoted, and you can also source it from wikipedia : https://en.wikipedia.org/wiki/Anti-pattern, https://en.wikipedia.org/wiki/Law_of_the_instrument – Pierre.Sassoulas Apr 19 '17 at 09: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 Apr 19 '17 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". – Thorbjørn Ravn Andersen Apr 19 '17 at 11:58
  • @ThorbjørnRavnAndersen I have heard some pretty dangerous music in my day. –  Apr 19 '17 at 17:40
34

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.

Jules
  • 17,614
  • 2
  • 33
  • 63
  • 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. –  Apr 19 '17 at 17:35
18

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.

Newtopian
  • 7,201
  • 3
  • 35
  • 52
13

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

wberry
  • 481
  • 3
  • 8
12

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

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 4
    It appears with the number of ideas, suggestions and discussion it aroused, this is actually correct. – SF. Apr 19 '17 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 Apr 19 '17 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. – This company is turning evil. Apr 19 '17 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. –  Apr 19 '17 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. Apr 19 '17 at 17:44
  • Funnily, I immediately thought of "Build vs buy" (with the usual implication that Buy is preferable, at least on a managerial level, at least around here) when reading the question. – AnoE Apr 19 '17 at 17:45
  • @AnoE If all needed software could be bought, what sensible company would build their own? Maybe "not reinventing the wheel" is so obvious that it does not even need a name? One of my favorite colorful metaphors is called *The Dinner Menu:* "Mom, what's for dinner?" "You have two choices: take it, or leave it." Those two choices are always there, and so one one really talks about the obvious. –  Apr 19 '17 at 18:36
9

Do not use a cannon to kill a mosquito

Confucius

AKA Overkill

Community
  • 1
Rufus
  • 1,437
  • 3
  • 9
  • 11
8

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.

jpmc26
  • 5,389
  • 4
  • 25
  • 37
5

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.

5

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.

nigel222
  • 255
  • 1
  • 3
4

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.

Jon Raynor
  • 10,905
  • 29
  • 47
  • 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 Apr 19 '17 at 01: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 Apr 19 '17 at 17:52
0

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.