Understanding the Wheel17 Jun 2009
I hate reinventing the wheel.
The phrase ‘reinventing the wheel’ is tossed around in software development, as it likely is in other professions, to signify you are probably doing something someone else has already done. Moreover, others who have solved your problem have hopefully had a chance to iterate on the solution several times to find an optimal answer.
With all this time and effort invested by others why bother trying to duplicate all that effort? After all, others have already solved your issue, no sense trying to out do them, is there?
Like all issues, reinventing the wheel in software development is not so black and white.
Jeff Atwood wrote about not reinventing the wheel unless you intend to learn more about it: http://www.codinghorror.com/blog/archives/001145.html
Joel Spolsky wrote a few years back that reinventing the wheel is a very good thing if that wheel happens to run your business: http://www.joelonsoftware.com/articles/fog0000000007.html
It is these two key points that will hopefully dictate when you as a software developer decide to break out the case of Mountain Dew and start coding your problem from scratch or to pull a code snippet off of http://stackoverflow.com/ and plug it into your production code.
I am a huge proponent of not reinventing the wheel. I used to expound to my developers constantly that I am a very lazy programmer. Why should I spend the time and effort to code something up from scratch if someone has already done all of the legwork?
What isn’t normally fully communicated to someone when I say, “be lazy and don’t reinvent the wheel,” is you have to understand the wheel to know that you are reinventing it. This is the point Jeff makes at the very bottom of his article, http://www.codinghorror.com/blog/archives/001145.html:
If anything, “Don’t Reinvent The Wheel” should be used as a call to arms for deeply educating yourself about all the existing solutions – not as a bludgeoning tool to undermine those who legitimately want to build something better or improve on what’s already out there. In my experience, sadly, it’s much more the latter than the former.
I get to be lazy, reuse my old code, and not reinvent the wheel because I understand the wheel I am about to not reinvent.
I have done a bit of legwork myself to understand the piece of code I am about to plug into my system before choosing to plug it in. I have done some research on the forms to see how others are tackling the same problems I have, and I have done some testing to ensure what I am about to use is going to work. With all of this legwork under my belt hopefully the next time I encounter a similar problem I won’t have to work so hard for a solution, in effect be a little lazy and modify or tweak an already existing solution to use in a new problem.
It is with this experience that one can become truly effective at producing robust software, learn from the past, and not treat every problem by starting with a blank sheet of paper.
However, one also needs to be smart enough to know when to break out a blank project in your IDE and start from scratch. As Joel points out in his article, if the piece of code you are about to borrow is a key piece of your product, and this code is going to differentiate your product from your competition you might want to get to know the ins and outs of that code yourself.
What do you do in your software or business that sets you apart from everyone else? Whatever that is, don’t outsource it or borrow it from others! If you do you are at the mercy of others for what you are claiming is your advantage.
Joel gives several examples in his article of items not to outsource those items are the cornerstone of your business. One more recent example Joel did not reference was Zappos.
Zappos sells shoes online. That is their whole business, online shoes. Not special fancy shoes you couldn’t buy a hundred different places, just normal run of the mill shoes.
Yet, they are one of the more successful companies operating today on the Internet.
Zappos prides themselves on their customer service and quick and speedy order fulfillment. Guess what are the two things they don’t outsource? The one part they can’t outsource, the actual delivery of the shoes to your door, they compensate by paying out of their pocket for overnight delivery on most orders to give the end user the allusion of faster than normal service and fulfillment. Zappos has taken to heart the idea of what sets them apart from everyone else is customer service, and they do everything in their power to ‘reinvent the wheel’ when it comes to that. They are reinventing the wheel to make a better wheel, a wheel more and more people are starting to use.
I leave you with these thoughts:
- Don’t reinvent the wheel.
- Understand the wheel well enough before making a judgment call to reinvent it or not.
- If the wheel is the corner stone of your software/application/business, you had better be reinventing the heck out of that wheel.