Code Craft
The art, science and craft of writing quality software

Sep. 20, 2005 - Three reasons to reinvent the wheel

Posted in Programming

I get so tired of the worn out expression, "let's not re-invent the wheel."  It's used as a conversation stopper to inform you that you are straying from the well worn path of software sanity.  There is no mention that this well worn path now employs nearly two million people to write what are essentially the same CRUD applications that were written on mainframes in the 1970s.  It is a statement that life is good and you should rejoin the flower people on the primrose path to happiness.  So, here is my answer, the three reasons you should reinvent the wheel.

The wheel sucks

The first wheels were actually relatively un-round slabs of stone.  Last time I checked these wouldn't fit to well on my new Jaguar XJ-39.  I'm actually glad I've got my run-flat-Aquatread-floating-on-a-cushion-of-air system.  I'm hoping that we can move away from wheels entirely some day and have vehicles that float less than an inch from the ground using the Bernoulli principle.

If the wheel can be improved, there is little doubt that any software written in the world today can be improved as well.  If you take the time to see what other people are doing and it looks like it sucks, it may just be possible that it does suck but they don't have time to reinvent the wheel or they haven't figured out how to do it. 

Oh, and your process may suck too.

You don't understand wheels

Not reinventing the wheel can also be code for, "I don't want to figure this stuff out."  The problem is that when we really don't understand what a tool is doing for us we are very likely to use the tool wrong.  According to my power-lathe manual, "Using this tool in a manner other than prescribed may result in serious injury or death."  Ouch, that's a Bad ThingTM.  As strange as it may sound, being willing to start writing your own tool may give you the insights to use other people's tools properly.  Along the way you may either build a smaller, simpler tool that meets your need OR you may figure out that someone else really has done it better and stop (pride cometh before a fall, stopping is ok).

Those of you who feel that just RTFM (read the fine manual) is good enough or RTFC (read the fine code) is faster haven't seen some of the same manuals and code that I've seen.  Many of us really do learn faster by doing.  My kids sure seem to learn better that way.  The mind set that personal experimentation has no place in the software development lifecycle could use some revision.

This goes triple for processes; XP can't be done without some groking.  You're better off making something up that makes sense than implementing something that doesn't make sense to you.

They don't sell wheels at the Kwik-E Mart

Sometimes you must do all your shopping at one store.  Maybe it's FOSS central or your local coffee vendor, but for various reasons the perfect tool is not for sale where you can shop.  You could catch the two-thirty train to Boston, buy that ever so perfect Mango-Squishie and come back with it; but is the trip worth it when you could make do with a Banana-Squishie instead?

I just realized I was speaking in code that last paragraph (well, since this is about programming it was more like anti-code).  Here's what I mean.  Often the perfect tool can be found, but its requirements aren't yours.  Maybe it is Windows only or it's Open Source and your company forbids it, or (and this is the most common) it has usage requirements that are at odds with yours.  These might include logging systems or databases, or a host of other "socket incompatibilities."  In these cases, re-invent at will.  Only you're probably not re-inventing, it's more like your making your own wheel from someone else's design.  Just because there exists A wheel somewhere in the world the problem of wheel-ness has not been solved universally.  You may still need to find (or make) one that fits your Model-A ford.

License to code

The next time someone tells you (inappropriately) not to reinvent the wheel, I hereby grant you permission to show them this: it is your personalized license to code.  Your license number is 103425-1a756.  It is hereby granted to you and is fully transferable both in part and in whole without precondition.  It may further be copied and reproduced and is valid for any purpose. 

That should shut them up!

Post A Comment!

Sep. 20, 2005 - Untitled Comment

Posted by Aristotle Pagaltzis, http://plasmasturm.org/
I think the problem in general is that wheel reinvention is done for the wrong reasons. Many people habitually reinvent half-assed wheels for production code. That??s the worst possible strategy.

First off, if you want to reinvent a wheel purely for edification, go ahead, you should. Maybe you should still play around with existing ones beforehand to get a feel for what??s already there, because learning from experience is the most complete, but also the slowest way to learn; it??s useful if you can help the process along. But you??re pretty much free to do whatever you wish when it??s on your own time for your own personal growth.

That said, it??s another matter altogether if you intend to put your wheel in production.

You need at least a decent view of the problem space and to know what you??re up against. I would be very wary of reinventing a wheel I didn??t understand. Are you confident that you can create a complete wheel that is as good as what??s already there? Of course, the size of the wheel is an important factor here: smaller wheels are easier to understand and easier to reinvent. A veteran with a dynamic language will compose his language??s components into a pretty usable web framework in a week. The same veteran will spend three weeks writing a basic but somewhat complete HTTP server implementation from scratch. He will take months to implement a fast, well-featured templating system, and even longer for a moderately scalable, performant general-purpose relational database. The ultimate wheel reinvention, writing your own operating system wheel, requires a *DAMN* good justification.

Sometimes you have such justification ?? even for writing your own operating system. And to paraphrase Joel Spolsky, by all means reinvent the wheel in your core competence. This is simply an issue of picking one??s battles wisely; you don??t want to stretch yourself too thin. Every line of code you write (instead of using someone else??s) is a line you will have to maintain. Is it worth it? The factors need to be weighed carefully, else you??re just acting irresponsibly.

What??s important is awareness. Sometimes you will choose to reinvent a wheel. Often you will not. Both are equally important. If you have a thorough understanding of your craft, you will know one case from the other.
Permanent Link

Sep. 20, 2005 - great points

Posted by soulcraft
There is no doubt that you are right. I wanted to have some fun at the expense of those who think that every good thing has been written and they need just piece it all together. In truth we are always balancing these kinds of things, to walk the steady path or to branch out on our own; to write or to use; to fix for the short term or refactor more broadly. While the license to code is free you have to pay the price when you use it.
Permanent Link

Sep. 20, 2005 - oops

Posted by codecraft
That last comment was from me (Kevin Barnes) I just forgot to switch which blog I was working on and ended up as the wrong user.
Permanent Link

Sep. 20, 2005 - Re:

Posted by Aristotle Pagaltzis, http://plasmasturm.org/
Yeah, I know, and I completely agree. There too many people making hard and fast rules ?? the less they understand them, the stronger they seem to cling to them.
Permanent Link

Oct. 8, 2005 - Rules

Posted by nobody
"There too many people making hard and fast rules ?? the less they understand them, the stronger they seem to cling to them."

I think this has a rather natural explanation (it may also have rather unnatural explanations but I am not aware of any): The less they know, the more they cling to what they know - simply because it is known. The less they know, the greater the relative scale of what is unknown, and venturing into what is unknown is riscy. The more they know, the less they don't know and thus the risc of venturing into what they don't know is notably smaller.

:)
Permanent Link

Nov. 17, 2005 - Dispatch the wheel

Posted by Anonymous
Wasn't Bernouli law about the even level of liquid distribution onto comunicating pipes? Is it so perfect to get rid of the wheel for it? And that does not apply to capilar pipes(vessels)
Permanent Link

Nov. 25, 2005 - I Hate Bush

Posted by Anonymous
http://gohate.com/_view/part_directory/section_B/id_9
Bush stands against everything that America stands for.
Permanent Link

Apr. 11, 2006 - Solute to those who like to reinvent the wheel!

Posted by Anonymous
(As long as you don't waste other people's resources), as long as it is really a bland new invention, don't copy any parts of the existing wheel. It is another trial for searching the global optimum. Nobody can guarrantee current one is the best one.
Permanent Link

Share and enjoy
  • Digg
  • del.icio.us
  • DZone
  • Netvouz
  • NewsVine
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • YahooMyWeb
<- Last PageNext Page ->

Kevin Barnes

Code Craft is the place for my thoughts, rants, ideas and occassional jokes on what it means to write code, why some people are better at it than others, and how we think about software in general.

Links

Home
View my profile
Site Feed (RSS)
Archives
Email Me
StorePerform
TechNexxus
Soul Craft (my stories and discussions)
My Wall

Joel on Software
Paul Graham
Patric Logan
Martin Fowler
Free Blogs
Free Blog



Copyright (C) 2005, Kevin Barnes. All rights reserved.

portfolio