Is reinventing the wheel really all that bad?

Question

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?

Answer 1

Depends..

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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.