Its common knowledge in programming that reinventing the wheel is bad or evil.

But why is that?

I am not suggesting that it's good. I believe it to be wrong. However, I once read an article that said, if someone is doing something wrong (programming wise) explain to them why its wrong, if you can't, then maybe you should be asking yourself if it is really wrong.

That leads me to this question:

If I see someone is clearly reinventing the wheel by building their own method of something that is already built into the language/framework. First, for arguments sake, lets assume that their method is just as efficient as the built in method. Also the developer, aware of the built in method, prefers his own method.

Why should he use the built in one over his own?

  • 18
    This is a great question. I don't think people should reinvent the wheel but it's important to challenge these ideas to make sure they hold up. Commented Dec 23, 2010 at 15:08
  • 4
    @Demian - That's actually a pretty good idea. If you can explain it then you're probably justified in doing it. Commented Dec 23, 2010 at 16:03
  • 3
    In all decisions, it's good to ask what your primary objective is, and then cause the other sub-elements to support the primary objective. If your primary objective is to deliver a quality product in a timely manner, then duplicating already-existing code is likely a detriment to this goal. If your primary objective is to create a better-thought-through library, then maybe it contributes to this goal. If you work for someone else, then you need to ask the question from their perspective, not so much yours.
    – gahooa
    Commented Dec 23, 2010 at 19:11
  • 5
    Reinvent if existing wheels really don't do the trick for your specific need, or... if you want to know how wheels work! An interesting article on this topic: codinghorror.com/blog/2009/02/…
    – lindes
    Commented Aug 22, 2013 at 19:04
  • 6
    Attributed to Douglas Crockford: The good thing about reinventing the wheel is that you can get a round one. Commented Dec 18, 2014 at 20:52

25 Answers 25



As with everything, it's about context:

It's Good when:

  • Framework or library is too heavy, and you only require limited functionality. Rolling your own extremely light-weight version that suits your requirement is a better approach.
  • When you want to understand and learn something complex, rolling your own makes sense.
  • You have something different to offer, something others' implementations do not have. Maybe a new twist, new feature etc.

It's Bad when:

  • Functionality already exists and is stable and well known (popular).
  • Your version adds nothing new.
  • Your version introduces bugs or limitations (e.g. your version is not thread-safe).
  • Your version is missing features.
  • Your version has worse documentation.
  • Your version is lacking unit tests compared to what it is replacing.
  • 3
    Alongside your first point (and inverse to your fourth), if the wheel is hard to deal with or - worse yet - inflexible, you really can improve it. This happens frequently with UI components in some areas, where the wheel turns out to be a train wheel, and only works in one track.
    – Magus
    Commented Feb 27, 2014 at 19:22
  • 2
    Hard to understand rings true for me. I just wasn't getting directed graph analysis so made one, and now I know. Now I feel confident to use a framework Commented Dec 8, 2016 at 7:29
  • 2
    I'd add a 4th for the "Good" column (though it rarely applies): if you understand the problem space better than the existing library. Java's de facto standard time library Joda was written because the built-in was hard to work with, and was rewritten as Java 8's de jure standard time library because they now understood the problem much better than when they wrote the original joda-time.
    – Morgen
    Commented Jun 7, 2018 at 6:09
  • Library bloat is increasingly not a valid concern, as tools like ProGuard become more common. Commented Jun 1, 2021 at 18:30

I think the case of a developer knowingly reinventing the wheel "because he prefers his own method" is pretty rare. Mostly it's done out of ignorance, and sometimes out of stubbornness.

Is it all that bad? Yes. Why? Because the existing wheel has most likely been crafted over time and has already been tested in lots of circumstances and against lots of different kinds of data. The developer(s) of the existing wheel have already encountered the edge-cases and difficulties that the reinventor can't even imagine yet.

  • 3
    Or laziness - that the can't be bothered to go and look for the alternatives or find it less interesting to go and do so that to write the code. Commented Dec 23, 2010 at 15:13
  • 11
    I've seen many cases where re-inventing the wheel was done out of arrogance, with an attitude that library/framework xyz is only for bad programmers that didn't know how to do it the "right way". Heck, I've seen that argument (in some fashion or another) on SO sites.
    – Bill
    Commented Dec 23, 2010 at 15:36
  • 3
    ... Which creates a recurring (the worst kind) burden of maintenance on the current or subsequent developers.
    – gahooa
    Commented Dec 23, 2010 at 19:13
  • 2
    This is what I was doing for years. I'd roll my own feature in a language because I had no idea that that functionality was already built-in.
    – Matchu
    Commented Dec 24, 2010 at 18:27
  • 4
    Since writing this post (geez) almost three years ago, I hired and fired a developer that I described in the first sentence as "pretty rare". He lasted a month. I'd tell him how we do things here and he would say "I hear what you're saying". It took me a month to hear the unsaid "...but it's wrong and I will secretly do everything but it" at the end of the phrase.
    – Dan Ray
    Commented Nov 2, 2013 at 12:53

Square wheels have to be reinvented. Efforts that suck have to be duplicated. Maybe there's a lack of documentation for the method, and the other programmer feels it's easier just writing their own rather than trying to figure it out. Maybe the way the method is being called is awkward and doesn't fit into the idiom of the programming language.

Just ask him what the deficiency is.

  • 11
    +1 Good metaphor "square wheels have to be reinvented".
    – Orbling
    Commented Dec 23, 2010 at 15:31
  • +1 for "Square wheels have to be reinvented" Commented Feb 25, 2019 at 5:44

In general, I avoid reinventing the wheel if the functionality I desire, or something approximating it, exists in the standard library of the language I use.

However, if I have to incorporate third party libraries, it's a judgment call depending on how widely used and esteemed the library is. I mean, are we talking about Boost or Bob's Kick-ass String-Parsing Tools 1.0?

Even if the library is generally well-known and highly-esteemed throughout the industry, it's still a third-party dependency. Programmers generally place significant emphasis on the virtues of code reuse, while often glossing over the danger of dependencies. A project with too many third-party dependencies is likely to fall apart in the long run as it slowly devolves into a maintenance nightmare.

So leveraging existing code is good - but dependencies are bad. Unfortunately, these two statements are at odds with each other, so the trick is trying to find the right balance. That's why you need to identify acceptable dependencies. As I said, anything in the Standard Library of the language is most likely an acceptable dependency. Moving on from there, libraries which are highly regarded throughout the industry are also generally acceptable (like Boost for C++, or jQuery for Javascript) - but they are still less desirable than the Standard Library because they do tend to be less stable than standardized libraries.

As for libraries which are relatively unknown, (e.g. the latest upload on SourceForge) these are extremely risky dependencies, and I would generally recommend avoiding these in production code, unless you are familiar enough with the source code to maintain them yourself.

So it's really all a balancing act. But the point is that just blindly saying "Code reuse good! Reinventing wheel bad!" is a dangerous attitude. The benefits of leveraging third-party code must be weighed against the disadvantages of introducing dependencies.

  • 5
    +1. I tend to feel the same way. I'm a lot more inclined to reinvent small wheels if using an existing wheel will create a dependency hassle than if the existing wheel is already there, set up and waiting to be used in any environment where I may need it.
    – dsimcha
    Commented Dec 24, 2010 at 1:16

If people didn't reinvent wheels, the world would be filled with these.. enter image description here

Here is a dialogue from my workplace:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

There are two options: either reinvent the wheel OR use Colorama. Here is what each option would result into:

Using Colorama

  • Maybe a bit faster to get running
  • Adding a third party dependency for something trivial
  • You continue being as stupid as before using Colorama

Reinventing the wheel

  • You understand how some programs are able to show color
  • You learn that special characters can be used to color on any terminal
  • You are able to color in any programming language you might use in the future
  • Your project is less likely to break

As you see, it's all up to context. Reinventing the wheel is something I do very often because I want to be able and think for myself and not rely on other people thinking for me. If however you are running on a deadline or what you try to implement is huge and already exists, then you're better off using what is there.

Update (after a few years of experience)

I update my answer since after some years of working on multiple projects, my opinion has slightly changed. Also to answer some of the comments.

First of all with re-invent the wheel we mean essentially creating a library for a specific functionality, when there's already at least a 3rd party library that already does that.

When to re-invent the wheel

  1. When you want to learn.

  2. When you know exactly what you need, but an existing library becomes overly complex to give you that.

  3. When the existing library overhead over-saturates the functionality you need. E.g. using NLP when you just need to count a few words in a document.

  4. When the functionality you're looking for, is not overly complex to do from scratch (e.g. rebuilding a whole new OS kernel).

  5. When cross-platform is not essential (if given by the 3rd library).

And ofcourse it all depends on context. Sometimes a 3rd party library might not be maintained properly, or maybe it makes more sense to just fork it and build on top.

  • 2
    +1 don't agree with you 100% but liked the image used to convey the idea. Commented Dec 19, 2014 at 16:14
  • This answer does somewhat circumvent that your employer is paying for your luxury of reinventing that wheel for your own educational benefit. Perhaps you should do that in your own time; if asked, your employer will probably say that he./she just wants the job done in the quickest possible time and if Colorama does that, crack on with it. Commented Jan 27, 2017 at 14:56
  • 2
    @NeilHaughton as I see it my "own" educational benefit is also the benefit of my employer.
    – Pithikos
    Commented Jan 27, 2017 at 15:21
  • Hmmm... your employer may of course not see it that way, and he/she is putting the bread on your table. Commented Mar 15, 2017 at 11:02
  • The library Colorama, itself was a reinvention of a wheel. There already was an interface to display colors in terminal (through special chars) and before it came out people were already doing it. The Colorama library reinvents the interface how to achieve the goal. So question here is more about if you gonna use a supposedly improved wheel, or do you use an old-wheel in your project? Reinventing the wheel in this case would be building Colorama2 that "improves" even further on top of what Colorama had to offer.
    – Ski
    Commented Jun 7, 2018 at 2:45

One useful reason to reinvent the wheel is for learning purposes -- but I'd recommend doing it on your own time. As more pre-canned solutions become available, and more levels of abstraction is provided, we become a lot more productive. We can focus on the business problem rather than the generic stuff that's been tweaked time and again. BUT, for that reason, you can sharpen your skills and learn a lot by trying to re-implement a solution on your own. Just not necessarily for production use.

One other thing -- if a concern is dependency on a third party library from a company that may disappear, make sure there's an option to get the source code, or at least a couple of other choices out there to fall back on.

By the way, if you do choose to implement your own, avoid doing this for cryptography or other security-related functionality. Established (and fully tested) tools are available for that, and in this day and age, it is wayyyyyy too risky to roll your own. That is never worth it, and it's scary that I still hear about teams doing this.

  • +1 A very good point on the learning perspective, in order to use a library effectively, you should really know intimately how it works. I do not like black box use of tools. Also excellent point on the cryptography libraries, too risky to roll your own on that score.
    – Orbling
    Commented Dec 23, 2010 at 15:33
  • I'd add that if there's a concern a third party library might disappear, that's a pretty good justification for writing a programmatic interface that allows one library to easily be swapped out for another.
    – user8865
    Commented Dec 23, 2010 at 16:23
  • Good point -- we use the adapter pattern just for this purpose, and it recently saved us when we had to swap out a third party FTP library. Commented Dec 23, 2010 at 16:44

There are two sorts of efficiency - processing / speed (that is how quickly it executes) which it may match and development speed which it almost certainly won't. That's the first reason - for any problem of reasonable complexity where existing solutions are available it will almost certainly be faster to research and implement an existing library than to code your own.

The second reason is that the existing library (assuming it's mature) is tested and is proven to work - probably in a far wider range of scenarios than a developer and a test team will be able to put a newly written routine through and this comes at zero effort.

Thirdly, it's way easier to support. Not only does someone else supports and improves it (whoever wrote the library / component), but it's far more likely that other developers will be familiar with it and be able to understand and maintain the code going forward, all of which minimises on-going costs.

And all that assumes functional equivalence, which isn't normally the case. Frequently libraries will offer functionality which you would find useful but could never justify building in, all of which is suddenly available for free.

There are reasons to roll your own - largely where you want to do something the built in function can't do and where there is a genuine advantage to be gained by doing so, or where the readily available options aren't mature - but they're less common than many developers would have you believe.

Besides, why would you want to spend your time solving problems that have already been solved? Yes it's a great way to learn but you shouldn't be doing that at the cost of the right solution for production code which is what I'm assuming we're talking about.

  • 2
    On your last line: in order to know how they are solved. Programming is dependent on experience after all.
    – Orbling
    Commented Dec 23, 2010 at 15:35
  • 1
    @Orbling - fair enough but you shouldn't be doing that in production code and I'm assuming that's what the question refers to. Shall amend. Commented Dec 23, 2010 at 15:42
  • @Jon Hopkins: Well production code usually follows on from the learning, unless done on your own time.
    – Orbling
    Commented Dec 23, 2010 at 16:17
  • @Orbling - I'd argue that you should never learn something for the sake of learning and then put it into production. Either something is production code in which case it should be the best solution, or it's for learning. There are times when they overlap but this wouldn't be one of them as it unless rolling your own was genuinely the best solution. Commented Dec 23, 2010 at 16:19
  • @Jon Hopkins: Ideally yes, but frequently there is no one on the team that knows how to do whatever it is, to the point where available libraries may not be reliably serviceable. Learning, or "research" as most people call it, is then a necessity. Yes, that's not exactly learning for the sake of learning, but it is learning to avoid future risk.
    – Orbling
    Commented Dec 23, 2010 at 16:24

Of course reinventing the wheel on a whim, out of ignorance and arrogance can be a bad thing, but IMHO the pendulum has swung too far. There's a tremendous advantage to having a wheel that does exactly what you want and nothing more.

Often when I look at an existing wheel, it either does way more than I need it to, suffers from the inner platform effect, and is thus unnecessarily complex, or it is missing some key feature that I do need and that would be difficult to implement on top of what's already there.

Furthermore, using existing wheels often adds constraints to my project that I don't want. For example:

  • The existing wheel requires a different language and/or programming style than I would otherwise prefer to use.
  • The existing wheel only works with the legacy version of a language (for example, Python 2 instead of Python 3).
  • Where there are tradeoffs between efficiency, flexibility and simplicity the existing wheel makes choices that are suboptimal for my use case. (I've been known to reinvent even functionality from libraries that I originally wrote myself in these cases. Usually it's because I wrote the library version of the function to be generic and reasonably efficient, when I currently need something that's very fast in my specific case.)
  • The existing wheel has tons of legacy cruft that's totally useless in the case of new code but makes life difficult nonetheless (for example, a Java library I use that forces me to use its crappy container classes because it was written before generics, etc.).
  • The way the existing wheel models the problem is completely different than what's convenient for my use case. (For example, maybe it's convenient for me to have a directed graph represented by node objects and references but the existing wheel uses an adjacency matrix or vice-versa. Maybe it's convenient for me to lay my data out in column major order, but the existing wheel insists on row major or vice-versa.)
  • The library adds a massive, brittle dependency that would be a major hassle to get up and running everywhere I want to deploy my code, when all I need is a small subset of its features. On the other hand, in this case I sometimes just extract the feature I want into a new, smaller library or just copy/paste if the library is open source and the codebase makes doing so sufficiently simple. (I've even done this with relatively large libraries I've written myself, not just other people's.)
  • The existing wheel attempts to be pedantically compliant with some standard that is both inconvenient and irrelevant for my use case.
  • 1
    I think this all boils down to: if the wheel suits your purpose, use it, if it doesn't, create a new wheel that does. Just don't be dogmatic about it one way or the other. Commented Jan 27, 2017 at 14:58

Reinventing the wheel is a great way to learn how a wheel works, but it is not a good way to build a car.


Often I use my own because I built it before I discovered the pre-existing one, and I am too lazy to go find and replace every instance. Also, I fully understand my own method while I might not understand a pre-existing one. And finally, because I do not fully understand the pre-existing one I cannot verify that it does absolutely everything that my current one does.

There's a lot to code, and I don't get a lot of time to go back and re-code something unless it impacts production.

In fact, one asp web app that is still used today has a fully functional chart which displays data in a tabular format and allows sorting/editing, however it is not a datagrid. It was built a few years back when I was first learning asp.net and didn't know of datagrids. I am kind of scared of the code since I have no clue what I was doing back then, but it works, is accurate, is easy to modify, doesn't crash, and the users love it

  • 2
    That's a reason not to replace it, not to do it in the first place. I assume that you wouldn't do the same now knowing that the alternative exists? Commented Dec 23, 2010 at 15:08
  • @Jon lol definitely not! And I originally read the question as why a developer would prefer his own method to a pre-existing one. Re-reading the question now makes me realize the reverse of that question was asked, but I'm leaving the answer here since it seems related and got some up-votes
    – Rachel
    Commented Dec 23, 2010 at 17:09

I recently blogged my thoughts on this topic. To summarize:

  1. It's almost always evil to build your own, especially true if its a function thats built into the language. But if you're evaluating an immature / questionably-maintained / badly-documented framework you found on the Internet against the possibility of writing your own, it could be a no-brainer.

  2. I think reinventing the wheel is a pretty awful analogy for a software anti-pattern. It implies that the original solution can never be improved upon. That is nonsense. The so-called wheel can become obsolete overnight, or its owners could stop maintaining it. The wheel has a different value at each system where it's used. So, it's often entirely possible to invent a better wheel.

  3. One major benefit of making your own framework is that you won't have to take responsibility for someone else's bugs. (This is Amazon's philosophy.) Think of it this way: which of these is better to tell a customer? -

    "Our website broke. It was someone else's fault, and we've logged a bug with its creator. There is nothing we can do about it except wait. We'll keep you updated."

    "Our website broke, and we were able to fix it immediately."


My personal rule of thumb:

Reinventing the wheel is good when you're just learning. If you have a deadline, you may want to use existing wheels.


I currently work for a bunch of cheapskates.

When the decision is made between "build or buy", instead of making a rational decision based on economics, the managers chose to "build." This means that instead of paying a few thousand dollars for a component or tool, we spend man-months building our own. Purchasing a wheel from another company costs money which comes out of the budget - which counts against mismanagerial year-end bonuses. Programmers' time is free and therefore does not count against year-end bonuses (with the additional benefit of dinging the programmers for not getting everything done "on time"), therefore a reinvented wheel is a free wheel.

In a rational company, the cost vs benefits of purchasing wheels made by others vs reinventing one's own wheels would be based on short-term and long term costs, as well as opportunity costs lost because one can't be making new widgets while one is reinventing wheels. Every day you spend reinventing the wheel is another day you cannot write something new.

Presentation on build vs buy.
Article on build vs buy.

If I see someone is clearly reinventing the wheel by building their own method of something that is already built into the language/framework. First, for arguments sake, lets assume that their method is just as efficient as the built in method. Also the developer, aware of the built in method, prefers his own method.

Why should he use the built in one over his own?

The built-in version will have had a lot more people banging away on it - thus finding and fixing more bugs than your homebrew code can ever have.

Finally, when your local developer leaves, and someone else has to maintain the code he wrote, it is going to get totally refactored out and replaced with what is in the framework. I know this will happen because my current employer has code that has been migrated to newer versions of VB over the years (the oldest product has been on the market for about 20 years) and this is what has happened. The developer with the longest employment in my office has been here 17 years.

  • To be fair, sometimes the "standard" version was put there as a reinvention of what most people ended up doing before the standard version was developed. IOW, the standard one is meant to be the "grand final reinvention". But switching to a standard, well-tested, much more robust and bug-fixed version can lead to bugs, because your application code makes assumptions that are true for your old non-standard version, but false for the new standard one.
    – user8709
    Commented Dec 24, 2010 at 4:57
  • 2
    In a rational company, if it is decided that vendor lock-in is acceptable, the company (being the buyer and dependent on the provider's offering) will need to establish good business relationship with the provider, as well as hedging against various business mishaps. Examples: refusal to provide support / fix bugs, price hike, changing contract terms, frivolous lawsuits, or leaving the business altogether. This hedging is also part of the cost, and it is often ignored. (Just like the in-house development cost being ignored.) Note: This cost does not exist on the built-in offerings.
    – rwong
    Commented Dec 24, 2010 at 7:36
  • Are you not forgetting that your misguided cheapskate employers are effectively providing you with more paid work than you might otherwise have? You ought to be encouraging them instead of complaining about it! Commented Jan 27, 2017 at 15:01

The thing about re-inventing the wheel is that sometimes there's no standard, off-the-shelf wheel that will do what you need. There's a lot of good wheels out there, in a lot of sizes, colors, materials, and modes of construction. But some days you just have to have a really light-weight wheel that's green anodized aluminum, and no one makes one. In that case, you HAVE to make your own.

Now that's not to say that you should make your own wheels for every project - most things can use standard parts and be better for it. But every now and then, you find that the standard parts just don't work, so you make your own.

The most important thing is knowing WHEN to make your own. You have to have a good idea of what the standard parts can do, and what they can't, before you start designing your own.


Whether or not to re-invent the wheel is a cost/benefit thing. Costs are fairly obvious...

  • It takes a lot of time to do the reinventing.
  • It takes even more time to document what you have invented.
  • You cannot hire people who already understand what you have invented.
  • It is all too easy to reinvent something badly, causing ongoing costs for the problems caused by the bad design.
  • New code means new bugs. Old code has usually had most bugs removed already, and may have subtle workarounds to issues you're not aware of and therefore cannot work around in the new design.

The last is important - there's a blog post somewhere warning about the tendency to "throw the old code away and start from scratch" on the basis that a lot of the old cruft you don't understand is actually essential bugfixes. There's a cautionary tale about Netscape, IIRC.

The advantages can be...

  • The ability to add features that existing libraries don't have. For example, I have containers that "maintain" their iterator/cursor instances. Insertions and deletions don't invalidate iterators. An iterator pointing into a vector will continue to point to the same item (not the same index) irrespective of inserts and deletes earlier in the vector. You simply cannot do that with standard C++ containers.
  • A more specialised design targeting your particular requirements and respecting your priorities (but beware the tendency toward the inner-platform effect).
  • Complete control - some third party cannot decide to redesign the API in a way that means you have to rewrite half your application.
  • Complete understanding - you have designed it that way, so you hopefully fully understand how and why you did so.
  • EDIT You can learn the lessons from other libraries without being caught in the same traps by being selective about how you imitate them.

One thing - using a third-party library can count as reinventing the wheel. If you already have your own ancient, well used, well tested library, think carefully before discarding it to use a third-party library instead. It may well be a good idea in the long run - but there can be a huge amount of work and a lot of nasty surprises (from subtle semantic differences between the libraries) before you get there. For example, consider the effect of me switching from my own containers to standard library ones. A naive translation of calling code wouldn't allow for the fact that the standard library containers don't maintain their iterators. Cases where I save an iterator for later as a "bookmark" couldn't be implemented using a simple translation at all - I'd need some non-trivial alternative means of indicating bookmark positions.


Being "bad" or even "evil" is rather strong words.

As always there are reasons for choosing a personal implementation over a built-in one. In the old days a C program might encounter bugs in the runtime library, and therefore simply have to provide its own implementation.

This doesn't apply for Java programs as the JVM is very strictly defined, but some algorithms are still very hard to get right. For instance Joshua Bloch describes how the deceivingly simple binary search algorithm in the Java runtime library contained a bug, which it took nine years to surface:


It was found, fixed and distributed in future Java distributions.

If you use the builtin binary search you just saved time and money by having Sun do the hard work finding, fixing and distributing this bugfix. You can leverage their work just by saying "you need at least Java 6 update 10".

If you use your own implementation - which would very likely contain this error too - you first need the bug to manifest itself. Given that this particular one only shows on LARGE datasets, it is bound to happen in production somewhere, meaning at least one of your customers will be affected and most likely loose real money while you find, fix and distribute the bugfix.

So, it is perfectly valid to prefer your own implementation, but the reason better be really good, as it is bound to be more expensive than leveraging the work of others.

  • +1 for relying on the platform to deploy bugfixes. On the other hand, it is up to the platform vendor to decide whether to distribute the bugfix. A different vendor may choose: (1) distribute the bugfix, for free; (2) withhold the bugfix until a major version upgrade; (3) distribute the bugfix to users of the latest version, but deny the earlier versions (4) refuse to fix altogether, claiming that it may "cause widespread incompatibility" and "only affects limited users".
    – rwong
    Commented Dec 24, 2010 at 7:49
  • @rwong, if you found a bug in the built in routine, your Best bet would be to provide your own fixed version. This goes under "a very good reason to dó so".
    – user1249
    Commented Dec 24, 2010 at 9:42
  • ørn: My point is that besides the benevolent vendor(s) you mentioned, there are also other kinds of vendors.
    – rwong
    Commented Dec 24, 2010 at 16:12
  • @rwong, in that case that qualifies for "a very good reason for choosing a personal implementation".
    – user1249
    Commented Dec 24, 2010 at 23:09

Arguments about "reinventing a wheel" is often used in wrong context of choosing to use a library but it's hardly similar thing.

Let's say I'm evaluating a library 'forms-plus', that just got popular recently and helps to deal with forms. It has a nice landing page, modern cool graphics, and a cult (oops, I mean "community") around it who swear how it makes making forms great again. But "forms-plus" is an abstraction on top of "forms". "forms" was possible but cumbersome to deal with, so abstraction that makes it easier is becoming popular.

New abstractions are appearing all the time. It's hard to compare them to wheels. It's more like a new control device and new manual to whatever-already-very-complicated-device you need to run.

One's valuation of this new device "forms-plus" will look different depending on personal experience. If I never built forms before then "forms-plus" will be very compelling because it's easier to get started. The downside is that if "forms-plus" turns out to be a leaky abstraction I will still need to learn "forms" anyway. If I was building forms without "forms-plus" then I will need to take into account time that I need to learn a new tool. The upside is that I already know "forms" so I'm not afraid of abstractions on top of it. Short term benefits often will be greater for new starters because there probably wouldn't be a new library if it didn't improve on something. Long term benefits will vary widely on quality of abstraction, adoption rate, and other factors already discussed in other answers.

After carefully evaluating the costs and benefits of using a new abstraction "forms-plus" vs using bare bone "forms" I make a decision. The decision is highly based on my personal experiences and different people will make a different decision. I might have chosen to use bare-bone "forms". Maybe later in time forms-plus will have gained more momentum behind it and become a de-facto standard. And maybe my own implementation over time might get hairy and start covering a lot of what forms-plus is doing. People coming at this later time will tend to criticize that I'm too keen on reinventing the wheel and I should have used an existing library instead. But it's also possible that at the time when I had to make a decision about "forms-plus" there were multiple other alternatives to "forms-plus", most of them dead projects by now, and possibly I gained by not choosing the wrong one.

In the end choosing the right tools is a complicated decision to make and "reinvention of wheel" is not a very helpful perspective.

  • This comment from a voice of experience should be upvoted more... +1
    – Alex D
    Commented Aug 5, 2020 at 12:26

If there's a working component that does what you need then why spend the time writing and debugging your own version? Similarly, if you've already written code to fulfill a similar function previously, why re-write it?

Joel wrote an article on Not-invented-here that speaks volumes about when re-writing code and software isn't and isn't useful.


As offensive as it may be to some, I've always found this term to be unclever when used by any form of engineer or in reference to a topic of creating or designing things. In fact, I can't help but to see it as disingenuous when considering the pressures to innovate in today's fast paced world. Repeating yourself (or ignoring adequate, pre-existing solutions) is never wise, but really, there's a reason why we're not all still staring at black screens full of green letters.

I understand "If it ain't broke don't fix it", though I guess such a phrase may sound ignorant to some. Yet with the current effort to re-invent the wheel for the needs of space travel, racing, shipping, etc, "don't re-invent the wheel" is pretty ignorant as well, and is nowhere near as clever as it sounds.

My background consists of leading many projects and I have had to work with many interns and other forms of green developers, and I have had to handle many naive questions that some would call 'stupid', and have also had to divert people from chasing rabbit wholes outside of the scope of their tasks. However, I would never discourage innovation or creativity, and have seen great things come from 're-inventing the wheel'.

My actual answer to the question: There are only two situations that make re-inventing the wheel is a bad thing:

  1. If it is not really needed
  2. If it is the other guy doing it when you could have

Edit: I can see by the drive-by down votes that I must have offended some. The one thing that I would like to add is that this phrase has always been a major pet-peeve of mine. I understand that my two cents might sound rather trollish, but I have no intentions to troll, cause fires, or offend.

  • +1: It’s bad if the other guy does it instead of you :-)
    – gnasher729
    Commented Aug 6, 2020 at 13:36

In some case it may be good idea to increase your autonomy:

Imagine three different teams using a common library that requires a lot of changes with potential different needs. This will force the three teams to coordinate their development and deployments with meetings and understanding each others need and code. The change of one team may break things in the other team's code. This may reduce the agility.

Another example is using a third party library. You may discover that you need to make changes. Even if you are willing to pay for support or contribute to open source you may find that the next version won't be ready during months. Developers may even consider that they do not want to cover your use case. You may end maintaing a fork of the open source git.

This is very context-dependant:

  • How big, stable, documented or supported is the library?
  • How many functionalities do you need now and in the future?
  • How probable is to need custom modifications?
  • Do anybody in the team know how to use it?

But please, do not reinvent Spring.


If you pull in some third-party framework, then you are responsible for the framework, you have to make sure it has no security problems, you have to keep up with new versions. It may be one day of work today, but you will have to invest many days in the future. Worse if you make changes that you have to merge into new versions again and again.

Ask yourself: Are you re-inventing the wheel? Or are you just reinventing how to make a cup of coffee? Are you just writing a few lines of code that every decent developer could write easily? Make sure that the new framework is really worth it, because you’ll pay the price for a long time.


There are a lot of different types of wheels

You can't put a bicycle wheel on a car. A shopping cart wheel is wholly insufficient for transporting rockets. A waterwheel is not appropriate for office chairs.

Maybe none of the wheels on the market are appropriate for the thing you want to do. That's when you invent a new one. Putting LEGO wheels on an airplane is a great way to make sure you kill your passengers.

This culture of "don't reinvent the wheel, ever" was what led to the leftpad fiasco. It led us down the path of React and virtual DOM instead of doing the much simpler and less error prone method of doing custom rendering directly to a canvas. That's essentially what games do and why they can run at 60+ FPS while browsers struggle to scroll text smoothly.

Use the right wheel for the job. If that means reinventing it, do it.

  • How many games are written in unreal or unity on top of opengl/Vulkan/DirectX and physx on the windows GPU stack? You can't write a large modern system in pure machine code, so the trade-off must be made somewhere. Commented Aug 3, 2020 at 23:33

Maybe it's just as efficient, but is it as robust? I think the most compelling reason to use a library over rolling your own is that the framework has so many people using it that they can find and fix bugs quickly. In-house developed library, while they may provide just as much (or more) functionality, cannot compete with a library with millions of users to provide testing in pretty much every use-case. You just can't beat that kind of testing in-house.


Well, his own method being as efficient as framework would be pretty rare because most frameworks still have bugs and no framework can give you an out of the box solution. Most programmers who can't think will never try to write anything at the framework level; they will just search Google for a ready-made solution. Any wise programmer will first see if there is a free framework that has the functionality he needs, and then write the solution himself if there isn't. Sometimes it is way too difficult to explain the current project situtation and the developer is the best judge.

Reinventing the wheel is not bad, it is a statement made by lazy people to avoid working hard. Even framework writers do reinvent; the entire .Net framework was reinvented to do what COM was offering.


I wrote a little article about this - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

In my experience, re-inventing has actually been great - although very lengthy and tedious. I would say, if you don't know exactly the programming models you are going to use, then write them yourself (if you have the time and energy). This will teach you about what exactly those programming models mean and you will become a better programmer ultimately. Of course, if you are working for a client and just need to get something up quickly, you will probably just want to do some research and find the right piece of software for you.


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