Do the following scenarios count as "reinventing the wheel" in your book?

  • A solution exists, but not in the language you want to use, and existing solutions can't be interfaced with the language you want to use in a clean, idiomatic way.

  • In principle you could get an existing library to do what you wanted with heavy modification, but you think it would probably be easier to just start from scratch.

  • What you're writing has the same one-line description as stuff that's already been done, but you're targeting a different niche. For example, maybe your problem has been solved a zillion times before, but in a way that's inefficient for large datasets and your code works well for large datasets.

  • 4
    "probably be easier to start from scratch" - it rarely is...
    – user1249
    Commented Mar 6, 2011 at 22:23
  • Also, "heavy modification" may not be suitable for everyone. In any case, before "starting from scratch", it is best to study the existing code carefully.
    – rwong
    Commented Mar 7, 2011 at 6:31
  • When people write "Example" write an example, not another abstraction for the same idea. Commented Mar 7, 2011 at 9:36
  • 1
    I think we should stop considering the wheel at this point and realize that we've taken the axle for granted.
    – user131
    Commented Mar 7, 2011 at 10:19

8 Answers 8


If there is an existing solution that in your eyes would be a practical solution, then not using that but creating your own solution would be reinventing the wheel. Other than that, it is highly subjective.

About your specific scenarios:

  1. You always want clean, easily maintainable and easy to understand code. That goes above reinventing the wheel, IMHO. Time-constrainst might make you want to break this though.
  2. If it is easier to start from scratch, do it. You will also probably get a better result if the code was tailored for the specifc need.
  3. If a solution is a bad solution for your problem, it isn't reinventing the wheel to create a new one, that is making a better wheel.
  • 1
    I would add if you have a solution that is rubbish rewriting it from scratch is some times good.
    – Erin
    Commented Mar 6, 2011 at 23:34
  • 2
    @Erin - if you're better off rewriting then it wasn't really a solution.
    – JeffO
    Commented Mar 7, 2011 at 3:14
  • @Jeff O, management might have thought it was a solution. I've worked with lots of bad VB6 code that truly needed a rewrite. Commented Mar 7, 2011 at 16:22
  • 1
    I like to tell people "I can build anything, but I can't force someone else to build new features into their library, or fix their bugs!" Commented Jul 12, 2011 at 19:30
  • @Kevin Laity: Then again, as long as the library is open source, you could fork it
    – Anto
    Commented Jul 12, 2011 at 19:31

Reinventing the wheel is what others accuse you of when your analysis indicates you should write something yourself and theirs doesn't.


I think re-inventing the wheel can be defined quite simply: when, in the long run, you do more work writing it yourself rather than using the library. Note that it isn't always clear how much work something may be in the long run. You might be able to hack together a prototype yourself faster than you can refactor your existing code to include the library, but, in the long run, when you add more capabilities or have to support the code, the library would work out better.

The bottom line is, you need to do some careful thinking about your situation when deciding whether or not to use a library. You need to decide if the library is easier for what you want to do now and easier for what you will do in the future. Knowing what you will do in the future isn't always straight forwards, but if you have a good plan, you should have a rough idea. That said, sometimes forecasts are inaccurate - you generally don't realise you've re-invented the wheel until after you've done it.

  • 1
    It's worth noting that in some cases, using an existing library may save on maintenance costs (e.g. if you use someone else's library to access the Registry, and if Microsoft changes the way 32-bit applications access the Registry, you may be able to simply get an upgraded version of that library without having to change the library-access code yourself), while in other cases it may increase maintenance costs (e.g. because the library relies upon being able to read some setting from the Registry even though code you wrote yourself wouldn't, and the author of the code never...
    – supercat
    Commented Nov 18, 2012 at 16:09
  • 1
    ...releases a version that can tolerate Microsoft's remapping of the registry so you end up having to change it yourself). Sometimes it can be hard to predict what effect the use of external libraries will have on maintenance costs, since it may depend upon things which are unknowable (like what changes Microsoft is going to make to their operating system to break existing code).
    – supercat
    Commented Nov 18, 2012 at 16:12

It's too broad and subjective to be possible to answer with any accuracy simply because each case is different.

It is perfectly acceptable to reinvent the wheel when necessary, the key is using your judgement to decide when the previous wheel is an acceptable solution and when it's just not round enough to give a smooth ride.

It's a question that needs to be asked almost rhetorically at times to ensure that the best approach is being used. You can often find a better algorithm in a book than most programmers can write in the time it takes to find it.


The bigger and the more complex the problem, the less likely a wheel exists that suits exactly your needs, and the more legitimate you are to rebuild it.

I think we should only apply "don't reinvent the wheel" to basic elements (functions that are already built in the platform, well-known design patterns...) or if the exact solution to your problem is available- but that is rarely the case.

Your 3 points don't count as reinventing the wheel to me.


It depends...

For the first two:

  • A solution exists, but not in the language you want to use...
  • In principle you could get an existing library to do what you wanted with heavy modification...

In both these cases it does make sense to write your own code. But consider this: does the existing solution contain any techniques, algorithms or routines that you could learn from? Ignoring these would be reinventing the wheel.

  • What you're writing has the same one-line description as stuff that's already been done... maybe your problem has been solved a zillion times before, but in a way that's inefficient for large datasets...

Three questions:

  1. A zillion is a lot. Have you really looked at all the existing implementations?
  2. Is efficiency your main problem?
  3. Do you need to code the optimal solution now (and re-write later)?

If the answer to any of these is "No", you're reinventing the wheel.

That said, I'm not convinced that reinventing the wheel is always a bad thing anyway:

  1. It is a great way to learn, and the only way to truly understand existing solutions.
  2. Other people's wheels may not be any good. It is the only way to make better wheels.
  3. Even if other people's wheel are great, you can sometimes make good business from making even better wheels.

Your first scenario, does apply to reinvent the wheel, its self explaining.

The second scenario, does NOT apply if the existing code requires little modification, but if it does, its a good idea to try to use similar properties, methods, and usage than an existing code, so other developers doesn't have trouble using your "wheel".

Be careful by the "its always better to start from scrath" approach, it may take more time than you expect.

The third scenario you mention, its the "practical" approach. The "given wheel" may do the job, but, in reality, consumes too much resources, memory, speed, etc.

I worked once in an application that require to show hierarchical data in a treeview control from single table. We already have a control that could do that, but supported several tables, per item.

In order to use it, I had to learn too many stuff, assign too many properties, executes too many methods, and IT WAS SLOW. A coworker insisted on use it, in order to "not to reinvent the wheel".

I did a new control, from a scratch, read a single table, program only a few easy-to-learn properties. And before I knew it, there was another coworker that took it from the shared code repository, and replace the previous control.


When the wheel you already have is "squared". By "squared", I mean that in surface, looks like it does look like a solution to your problem, but after a good look, you get to the conclusion, that not.

It depends if you have the skills, and time, (and your company authorization), to reinvent the wheel.


First read this excellent article by Joel Spolsky: In Defense of Not-Invented-Here Syndrome

Then all the technical reasons become really minor nuances. If you feel that this software is critical for your job, then rewrite it. Yes it is "reinventing the wheel" but it's probably worth spending time on writing and maintaining. If its not critical, then just use what is available.

... if you've ever had to outsource a critical business function, you realize that outsourcing is hell. Without direct control over customer service, you're going to get nightmarishly bad customer service -- the kind people write about in their weblogs when they tried to get someone, anyone, from some phone company to do even the most basic thing. If you outsource fulfillment, and your fulfillment partner has a different idea about what constitutes prompt delivery, your customers are not going to be happy, and there's nothing you can do about it, because it took 3 months to find a fulfillment partner in the first place, and in fact, you won't even know that your customers are unhappy, because they can't talk to you, because you've set up an outsourced customer service center with the explicit aim of not listening to your own customers. That e-commerce engine you bought? There's no way it's going to be as flexible as what Amazon does with obidos, which they wrote themselves. (And if it is, then Amazon has no advantage over their competitors who bought the same thing). And no off-the-shelf web server is going to be as blazingly fast as what Google does with their hand-coded, hand-optimized server.

This principle, unfortunately, seems to be directly in conflict with the ideal of "code reuse good -- reinventing wheel bad."

The best advice I can offer:

    If it's a core business function -- do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house...

If you're developing a computer game where the plot is your competitive advantage, it's OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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