Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels

blog
43

Pure hubris to say it’s worth the time to reinvent the wheel. I’ve been on too many projects where the architect said, Hey, let’s create our own data structure kit/UI layout template manager/time date libraries because the ones out there just don’t do what we need…

In EVERY case, they wasted their time, and ultimately, the company didn’t get product out the door because of it. Every time.

Don’t reinvent the wheel unless you’re one of the 0.05% of people smart enough to get it right. The time and effort were already spent getting it right by people who needed it more badly than you.

With that said, the JoS post stands–if it’s your core business, you’d better write it yourself rather than depend on someone else. But 99% of the Reinventing I’ve ever seen, was not this type of code.

Perspective is key here.

44

Doing something that you know can be done is not invention.

45

Sounds like a Mikrosopht .NET propaganda. Anyways, does writting a compiler for a new programming language means reinventing a weel? If not, how come there is so much computer languages out there? :stuck_out_tongue:

46

Sometimes you have no choice but to reinvent wheels though.

Look at how many productized wheels cannot be relied upon because the vendor turns them upside-down from release to release, with releases coming and support dropping on a 2 year cycle.

Things like Biztalk or SharePoint from Microsoft. Things like FileNet or WebSphere MB from IBM. Unless you’re creating one-off demos you can’t even use these as building blocks, certainly not in enterprise applications. They’re moving targets.

The same has even become true of underlying platforms, like .Net, Java, and their ecosystems.

47

good post. personally, i love reinventing the wheel as a learning experience, and sometimes its possible to outperform existing solutions… but 3rd party libraries are still an invaluable tool. :slight_smile:

48

reminded me of this:

Reinventing the wheel certainly is annoying, but as long as all other
wheels are square…
-Reimar Döffinger

49

To just throw a word into this discussion that wasn’t mentioned before: Copyright.

50

The good thing about reinventing the wheel is that you can get a round one.

Douglas Crockford’s response about JSON as reinventing XML’s wheel.

51

This is fine advice for the business owner who is not consulting for someone else, but don’t reinvent the wheel on the clock. Unless you and the person who pays the bills have explicitly agreed that a whole new wheel is one of the necessary deliverables of a project, your self-indulgent exercises in software experimentation are not appropriate. Also, keep in mind that your individual work may be part of a larger effort in a long-lived product. If you leave the beaten path, you had damn well better leave some breadcrumbs behind you for the next poor developer to follow. Good, clear documentation of some sort is essential. Otherwise, your super duper, way cool code is going to be unceremoniously dumped shortly after you turn your back. Finally, be absolutely certain that you are actually doing it better, and are not missing good reasons for using a more standard approach. For example, don’t make changes that will require a total rewrite if an underlying framework is to be upgraded.

52

Wow, what troll bait. I’m ashamed to post a comment on a blog so desperately posting purely to start a flame war. However this needs to be said.

Your blog posts are read by many people with impressionable minds. Please stop spreading idiotic ideas like this. While I’m sure in the .NET world there is much less choice for free high quality libraries, for the rest of us, we have smart people writing good libraries that we can reuse in our projects to save us time and make us more money on the bottom line. Should I write my own openid implemention or use someone else’s, which has been tested and debugged by hundreds or thousands of devs? The answer is pretty obvious.

53

Time is the concern in this argument - low hanging fruit and wheel reinvention are both ways to speed up development time while making an attempt to keep quality up as well. If you’re under a deadline, and know you won’t have much time for testing before release, sometimes it’s a better bet to go with something established and ‘safe’.

But you’re totally right - if you don’t have that constraint, then it’s completely to your advantage to ‘DIY’. You learn more by doing then anything else - and if you always do it yourself, you’re going to keep learning. Which is important, if you’re a programmer.

54

I think reinventing the wheel in a sane way is more complicated than just IF you.want_to_learn(wheel.internals) THEN you.build(wheel) ELSE you.sleep).

There are certainly strong factors that make you rebuild a wheel.

  • Think licensing trouble. Let’s say, you have invented some sophisticated image recognition tool that is far better than all the others on the market. Do you want to use that GPL-library, that makes you give out all the source-code (and thus, all your secrets?) Certainly not. Thus, reinventing the wheel, ho.

  • of course, as Jeff said, learning about wheels. If it makes you a better user of the library or generally a programmer, rebuild it. However, if you rebuild something for yourself, you should judge very very carefully where you use it. You certainly don’t want to use a 3D-engine you built in a few days for educational purposes in order to build the glorious Quake5 or Quake 6 or use your own HTTP-incompatible webserver in production applications.

  • think of maintainability and especially extensibility. For a certain size of software or software components, it is actually easier to just build your own wheel instead of searching and using an external component. Fixing a bug in your own solution will be something like Adding a unittest, searching the codepath thatis bad and fixing something. Of course, you do not want to reimplement matlab or pthread with that, but many logging frameworks contain a lot of cruft.

Of course, and I will repeat this, you need to think carefully if you want to release your new wheel into the wild, because if you release something into the wild, prepare to add to the pool of low quality / awkward solutions, prepare to maintain, prepare to extend. But if you keep this in mind, then you can reinvent the wheel and release it.

55

I went out on a limb a month or so ago, and wrote an article about the exact same thing. If I only knew I was in such good company, I would’ve written it sooner.

I’ve been successfully reinventing wheels for a few years now. My code almost always work better for my purposes than any of the preexisting options. But as you said, the only reason that’s true is because I exhaust all of the preexisting alternatives before I write one line of my own code.

Bob Lee’s quote hit home for me most of all, saying in just a few sentences what it took me a few paragraphs to get out.

Thanks for the great research Jeff. If anyone’s interested:

On “reinventing the wheel”, and why that’s rarely the case

56

So there is this point:
This later became a source of frustration to Rather, who, as the marketing arm of FORTH, Inc., often bid jobs on the assumption that since Moore had just done a similar project this one would be easy – only to watch helplessly as he tore up all his past code and started over.

And I have to agree with Rather. In the end you need to ship something in a reasonable amount of time. Users don’t are about the internal prettyness of the code. Compiler and library writers get a bit of a break because of the hopefully massive reuse of their systems but general programs, ha!

Just look at Forth, while there are were a billion implementations where is it today? Maybe if the focus was on getting something out the door things might be very different for Forth. I wonder how many contract where soured or outright lost due to Moore re-writing code that was working.

Don’t get me wrong, as a programmer I love re-writing code. Polishing it to a nice shine. Getting the change to work it over again in the future. But I have to eat and it’s not my decision anyway. It’s whoever is paying the bills. So I code in my spare time. Sometimes for work, sometimes for fun projects.

John

57

Jeff,

I have to ask: is this post motivated by the fact that stackoverflow.com contains a lot of reinvented wheels and you feel a bit guilty about it and you are in need of some positive reinforcement?

58

The sacred 80/20 rule applies here!

If the wheel is in the 80% which does 20% of work and that don’t make competitive difference, don’t waste time reinventing the wheel, spend it to do something more useful.

If the wheel is in the 20% which does the 80% of work, and usually make the competitive difference, you would be fool to not, at least, try to reinvent a better wheel… since you are selling wheels, or, you are selling for how good your weels are!

59

@matt
build me something that works in the quickest time possible! Don’t reinvent unless it is a critical success factor FOR THE CUSTOMER!

Ah Matt, do you mean works right now or works for a long period of time and is easy to maintain?? If the stuff is throw away then yeah, but otherwise it’s better to take a little time thinking. Hardly anything is throw away, even the stuff that’s meant to be.

Design Patterns - I use frameworks built on them. Very rare to actually have to dust the books off. I find the whole DP debate rather stale, I do have recourse to the law of Demeter and avoiding train wreck dependencies blah.hlsd.blu.gordfe.yyy == 3 kind of thing. But that’s just common sense after it’s burned you a few times.

60

i try to explain this basic concept to a friend of mine who always gets in over his head with big grandiose projects - how are you going to do something that has never been done before if you can’t even competently do something that HAS already been done before?

61

I agree, reiventing the wheel is part of learning and i IMO essential (but do it on your own, at your own expense since it’s most often to your advantage alone)

I’m never confortable with using a library to do something that i haven’t done before, i have to know what it’s doing (70-80% at least, i don’t need to know the exact implementation).

If you were building a car, you’d want to know everything about the wheels so that you can find the most suitable set and learn about how they impact the product.

62

I ALWAYS reinvent wheels, pretty much on a weekly basis. Why would anyone do anything that stupid? The first wheel was made out of stone. The person creating the first wooden reinvented it. The person creating the first rubber one reinvented it. The person creating the first rubber one filled with air reinvented it. So if you need a wheel today, will you buy one made of rubber and filled with air or will you buy one made out of solid stone? I’ll guess you go for the first one… but if nobody had ever reinvented it, your car would still use stone wheels.

When I go out to buy an actual wheel, I don’t reinvent it. Why? I have absolutely no idea of wheels. I don’t know how to make a good wheel. I don’t even know how to make a poor wheel. And I’m absolutely the wrong person to come up with a brilliant idea how to make better wheels.

I’m a programmer. I have no idea of wheels, but I have ideas of code. Taking code from someone else means:

  • I must assume he created the fastest code possible
  • I must assume he created the most resource friendly code possible
  • I must assume he created bug free code
  • I must assume he created the best possible interface

and then I just use his code and it saves me hours of work. Have you ever considered that none of the above might be true? His code may be way slower than possible, using way more resources than necessary, it may have (still undiscovered) bugs, and the interface might really suck. What makes you believe, just because he has written some code, that this is actually perfect code? Because he’s a genius? The programmer of an API may have half the programming knowledge you have, one quarter of your experience, and his grade point average in math might have been two grades worse than yours throughout his whole education career. Do you know that is not the case? However you are willing to just blindly trust his code? Why?

Don’t get fooled by the fact that thousands of other projects use his code. Just because thousand other team leaders are too lazy to reinvent that wheel and just take the library already there says nothing about the quality of this library! The only you code of that you can control the quality is your own code (unless you do code audits on other people’s code).

I have already reinvented the wheel just to find out that when benchmarking my code, it beats the original code in speed, it uses less memory, it is multithread-safe (while the original one was not), and the API exactly meets my needs. I already reinvented the wheel just to find out my code sucks in speed, it eats memory like popcorn, it has no advantages over the other code and my API doesn’t look much different to the original library. Wow, big waste of time, right? Not necessarily. First of all I proved that the exiting library is of high quality (or let’s say the quality is better than the best thing I can produce)… alone this insight was worth the work. And the second interesting thing is that even knowing my wheel is worse, it may be still good enough for my project and the advantage is that I have total control over my wheel, while the development of the other one takes part behind my back.