Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  Jon Hopkins Dec 23 '10 at 15:08
@Demian - That's actually a pretty good idea. If you can explain it then you're probably justified in doing it. –  Jon Hopkins Dec 23 '10 at 16:03
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 Dec 23 '10 at 19:11
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 Aug 22 '13 at 19:04
Attributed to Douglas Crockford: The good thing about reinventing the wheel is that you can get a round one. –  Joel Etherton Dec 18 at 20:52

23 Answers 23

up vote 44 down vote accepted

As I've once posted on StackOverflow, reinventing the wheel is often a very good choice, contrary to popular belief. The main advantage is that you've got full control over the software, which is often essential. For a full discussion, see my original post.

share|improve this answer
+1 The most important point is that it is fully under your control and you know it inside out. Debugging other libraries can cause major headaches, if at all possible, and to say that all the mature libraries are bug-free is optimistic to say the least. –  Orbling Dec 23 '10 at 15:30
The Excel team even went as far as to write their own compiler because they wanted no external dependencies which might impact the project. This is a valid point but how critical that control is the main question. –  Jon Hopkins Dec 23 '10 at 15:59
+1. Once in a my former life as an MFC/VC++ programmer, we used a third party library for various GUI components, which turned out to be a total nightmare to maintain. These things became deeply hooked in the software and couldn't be removed (without spending unrealistic man-months-which-we-didn't-have of effort). I am absolutely certain that any initial time saving from not having to roll our own grids and layout managers was blown apart by orders of magnitude over the years from having to maintain that monstrosity. –  Bobby Tables Dec 23 '10 at 22:27
@Guzica, an unfortunate choice is not necessarily enough to generalize, and other libraries exist which are well maintained and a good choice. The question is whether the original decision was researched well enough? –  user1249 Dec 23 '10 at 22:52
On the upside, if you use a pre-existing wheel, you've usually got LOTS of help, often nicely indexed by Google, to assist you in debugging it. –  Dan Ray Dec 24 '10 at 17:56


As with everything, its 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 suites your requirement is a better approach.
  • When you want to understand and learn something complex, rolling you own makes sense.
  • You have something different to offer, something others' implementations do not have. May be a new twist, new feature etc.

It's Bad when:

  • Functionality already exists and is known to be stable and well known (popular).
  • Your version adds nothing new.
  • Your version introduces bugs or constraints (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.
share|improve this answer
+1 Context is king –  nXqd Aug 14 '12 at 11:12

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.

share|improve this answer
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. –  Jon Hopkins Dec 23 '10 at 15:13
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 Dec 23 '10 at 15:36
... Which creates a recurring (the worst kind) burden of maintenance on the current or subsequent developers. –  gahooa Dec 23 '10 at 19:13
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 Dec 24 '10 at 18:27
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 Nov 2 '13 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.

share|improve this answer
+1 Good metaphor "square wheels have to be reinvented". –  Orbling Dec 23 '10 at 15:31

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.

share|improve this answer

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.

share|improve this answer
+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 Dec 24 '10 at 1:16

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.

share|improve this answer
On your last line: in order to know how they are solved. Programming is dependent on experience after all. –  Orbling Dec 23 '10 at 15:35

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

share|improve this answer
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? –  Jon Hopkins Dec 23 '10 at 15:08

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.
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Reinventing the wheel can be a great way to learn how something works - and I recommend reinventing for just that purpose on your own time - but when writing an application why reinvent if there are well established solutions that already do the same thing?

For example, I would never write JavaScript code from scratch; instead I would start with jQuery and build my applications on top of that framework.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

protected by gnat Dec 22 at 19:42

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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