What considerations should be made before reinventing the wheel?

Question

All too often I see other people reinventing the wheel, and when I do, I wonder what factors played into their decision to do so.

There are times I reinvent the wheel consciously, merely because I am interested in the mental exercise, and other times without realizing it because of a lack of research.

What are considerations you use before making the decision to reinvent the wheel?

Answer 1

Here are some thoughts:

• Is what is available free or paid? If paid, do I need all the features, and if not, then compared to the cost of developing the features I need, is the already available less or more?
• If you don't like the performance, usability, etc. of what is available.
• Licensing restrictions.

Answer 2

Your lack of faith in already existing implementations could move you to reinvent the wheel. Often there are libraries available, but they have not been tested enough or you just think (or know) their quality is poor.

Also, license compatibility!

Answer 3

Here's another way to think about it: the things you do yourself are the things you provide value for and differentiate yourself with. If it doesn't do either of those, don't bother. If it does any of those, then you should probably bother.

Of course, research and education are valid reasons also. Just don't ship those.

MSN

Answer 4

It always depends on what your going to be using it for. For example, if something that does what you need exists, but it doesn't perform as fast as you would like or it's not quite as extensible as you want, it may be a good case to write your own version.

Many software projects that rely on other people's code can run in to problems because that code wasn't written with their specific usage in mind.

This is why the whole "Lego building block" method of programming still isn't really a possibility, as most of those "legos" would have to be tailored to that specific project in the end anyways.

Often times I've even found that I've spent the time to write a complete abstraction/compatibility layer to a third-party API so that it will mesh with my code better and I have more control.

Answer 5

Before re-inventing, make sure you really need a wheel.

Answer 6

Sometimes you need to build a wheel.

Answer 7

I recently built a blogging tool from scratch. No, I'm not joking.

The problem was I knew that even if I started off with a good off-the shelf solution (like Wordpress) I was going to spend a lot of time customizing it. For example, it needed to integrate with the existing authorization system and it needed to use the existing WYSIWYG editor. (No, I didn't reinvent the editor, but I had customized it. :-)) And it had a couple of extra (albeit minor) features that you don't find in a typical blog.

In the end, I think I saved myself a lot of frustration. Building a basic blog was easy. It's a well understood problem, and I had no trouble designing and programming the specific features I needed. I spent most of the time on the "custom" parts that I would have had to build into an off-the-shelf solution anyway. And that work was easier because I was starting from scratch rather than modifying an existing system.

I felt vindicated the other day when I came across this nugget in Robert L. Glass's Facts and Fallacies of Software Engineering.

Fact 19: Modification of existing code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.

Answer 8

Consider that you may inadvertently reinvent the flat tire. If what you're developing is for production work you should do your research and use an existing wheel. If it's for learning purposes, then you should feel free to experiment.

Answer 9

One consideration I think is often overlooked is the "experience cost" that's already built into existing, working systems. That's the sum of all the time spent debugging problems and doing the tweaking needed to integrate with other code. Often, this makes the code uglier or the interface more complicated that you'd expect when first defining whatever problem is to be solved, but you shouldn't disregard that making some wrapper code to hide the warts of an existing library or component is a lot easier than writing new code that gets all the little unexpected details right.

Answer 10

I reinvent a lot of wheels myself, generally either because:

a) The existing wheel is just far enough off from what I actually need that I'll end up spending more time customizing it than it would take to write my own.

or

b) I need a simple screwdriver, but all I can find are 42-function swiss army knives and I don't want all the baggage of the existing tool's extra complexity and/or find it to be documented poorly-enough that figuring out how to make it just do what I need (without invoking any of the other 41 functions) would be likely to take longer than just writing my own.

Reading over that, I guess it basically comes down to "I reinvent wheels when the existing wheels are either too specific or too general."

Answer 11

I often reinvent the wheel when existing wheels would require enough brittle glue code to make them more trouble than they're worth to reuse, or would constrain other aspects of the project too much. For example, maybe the wheel I need is in a different language than the one I'm using or want to use and interfacing things would be non-trivial. Maybe the existing wheel is a command line tool without a well-defined/documented API and I would have to invoke it using a bunch of shell commands and then read in and parse its output, rather than just calling a function. Maybe the existing wheel only does approximately what I want it to (for example, expects input in a completely different format than I'm using, or outputs data in a completely different format than I want), and wrapping it to make it do exactly what I want would result in lots of brittle kludges.

Answer 12

If we don't reinvent the wheel, how can we improve it? A wheel is much more than just a round thing. In fact, not every wheel is the same. Ever seen the steering wheel of a 19th century cutter? Try driving with that on your axles.

My point is, "reinventing the wheel" is a cliche that is all too often applied to any situation where someone is doing something that's already been done. Just because something has been done before doesn't mean it's not worth doing again. That's how we learn and improve.

Answer 13

I keep wondering why we spend so much energy reinventing wheels, when we ought to be inventing wings.

For me, reinventing the wheel is almost always a waste of time; there isn't enough time to do all the creative non-wheel coding I have in my mind as it is. Why diminish availability even further?

Answer 14

Writing your own implementation certainly has its advantages over reusing a ready made third party module:

• The features match your need exactly.
• There is as little code to understand as possible, as the implementation matches your case exactly. This is a large benefit when you need to write an extension, as there is less code to understand and to modify.
• Evaluating a ready made module is very time consuming. Furthermore, some shortcomings will surface only after extensive use, when it is too late to switch to another product.
• You have full control over in-house code.
  • Getting a ready made module extended by a third party often causes a big communication overhead (discussions with the developers maintaining the ready made module).
  • Inversely, you might be forced to break backward compatibility of your application if the developers choose to break the component's backward compatibility.
  • On the other hand, branching the component's (open source) code is untempting because you won't be able to reap benefits from bugfixes and extensions.
• The license agreement may be too strict.
• You can provide unique functionality. If the component is heavily reused, all client applications will have a similar feel. For example, almost all applications offering a rich text editor provide the same user experience as they use the same rich text GUI module. This is undesirable for your application's core functionality.

All previous remarks assume the ready made module is open source. In most cases, when using a closed source module:

• There is far too little documentation available, forcing you to start programming by trial-and-error, which is time consuming.
• It is hard to get bugs fixed. In most cases you'll find yourself patching around the bug, making the client code more complex.
• It might prove impossible to get extensions implemented.
• You suffer from vendor lock-in. This is especially true with frameworks.
• If the original developers drop maintenance you face a big problem of finding and implementing a replacement.

There certainly are situations in which code reuse is the best option, but it is not always the best choice. Reuse in software development is certainly different from the reuse of bricks. Building software is much more complex than building a wall, and software components need to evolve far more rapidly than bricks.

Answer 15

Sometimes, usually under a "startup" mindset, a business may wish to develop critical parts of its software by itself to increase their value through intellectual property (IP).

You see this happening all the time in .com's, but it happens elsewhere too.

Answer 16

I've slowly come to the conclusion that the pendulum has swung too far with regard to reinventing the wheel. Sometimes the only way to improve on the status quo is to make a clean break with it. You should consider reinventing the wheel if you:

• Need to remove some poor design decisions, unnecessary features, etc. that are thoroughly baked into the existing wheel.
• Want to break backwards compatibility where it's severely constraining the evolution of the existing wheel.
• Have fundamental disagreements with the designers of the existing wheel about what the design priorities should be.
• Want to create a wheel that takes full advantage of being built on top of newer, better lower-level components. For example, much very efficient numerics code is written in Fortran or C. Most of it works well but has a horrible API and an inscrutable implementation. It can also be a pain to interface with from other languages. If you don't need the absolute best performance available but do need a nicer API and the ability to understand and extend the code from within a modern, high-level language, it can make sense to rewrite code in D, Java, Python, C#, or some other language that you actually would want to use.
• Last but not least, if the existing wheel has restrictive licensing.

Answer 17

No consideration. Never reinvent the wheel.