

Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels - bdfh42
http://www.codinghorror.com/blog/archives/001145.html

======
mechanical_fish
This is an important point to understand. Otherwise you will grow up to be one
of those curmudgeons who refuses to comprehend why all the kids today insist
on reinventing your language of choice, only with a different syntax, a
slightly _different_ subset of the features of Common Lisp, and kernel-level
support for Twitter. (Which is crazy, since Twitter is just a fad. We had IRC
back in 1988! Grumble grumble grumble.)

The way to understand things is to take them apart and put them back together,
repeatedly, preferably with slight variations each time. It was true with the
wind-up alarm clock I had when I was a kid, and it's true with software,
today.

Of course, you do have to be careful. The CW cautions you against reinventing
the wheel, not because rebuilding something isn't the best way to understand
it, but because many programmers consistently overestimate the utility of
understanding something as opposed to merely shipping it and moving on -- or
just skipping it and buying an off-the-shelf solution. Our personalities tend
in this direction and have to be watched. A year or two ago I spent valuable
hours figuring out how to configure a local Linux mail server to handle
encryption. The resulting solution worked, but I feared it was a bit delicate.
So I slapped myself on the head and started paying $30 _per year_ to Fastmail.
(Which has apparently since fallen to $14 per year. And, of course, Gmail
offers much the same for free.) I don't _have_ to understand mail server
configuration! That knowledge adds nothing to my life!

~~~
timf
" _many programmers consistently overestimate the utility of understanding
something as opposed to merely shipping it and moving on_ "

I agree and want to add that it's not just overestimating the utility of
something that is a problem but _underestimating_ the quality of something
because you did not write it. Of course that can really be true sometimes but
more often not. You need to investigate and make the decision process more
fact driven.

I do disagree with that statement in the case that you're just plain
interested in something: no reason not to satisfy your curiosity if you have
the time. You will probably learn _something_ even if it is not the most
practical thing in terms of the here and now of your project. The latter is
what I thought we're discussing here though, the actual practical things to do
under time pressure.

------
patio11
I did a bit of wheel reinventing today, for one of my personal Canonical Black
Holes Of Developer Time examples, too: I wrote a shopping cart.

I really, really did not want to do this -- that is why I've been using
somebody else's shopping cart for the last two years. But there were two
outstanding usage niggles with their cart, and my intuition from previous A/B
testing is that these two niggles were going to cost me a few thousand dollars
this year.

So I specced out a pretty minimal replacement -- take open source library A,
write a very little connecting code, hook into shopping cart service backend
B, get done in 2 hours. Of course it ended up taking 8.5, and I've still got
one bug from myself, one bug Javascript bug in Firefox 3, and one apparent bug
in either the shopping cart service or Google Checkout itself.

Bah.

But, on the plus side, the new cart looks great, provides for a much better
user experience, and is bugs-in-your-teeth fast compared to the old one. After
I get the code a little cleaner I'll write up the design rationale and how I
went about building it -- maybe somebody can save themselves an hour or three
that way. Because just because we have to reinvent the wheel doesn't mean we
have to reinvent the spoke, too.

------
lgriffith
The best way never to have to ship anything is to rewrite everything.

The best way to have a really good product is to write all the critical stuff
from scratch.

The point of wisdom is to be able to determine what is actually critical and
what isn't.

~~~
timf
I don't think "critical" is the right word. Every single software layer you
build on top of is "critical" (down to the OS doing malloc and threads
correctly, etc). If something is both critical and already pretty bulletproof,
it does not make a lot of sense to go there.

I don't have any generalization to offer, I personally make the reuse-or-build
decision on a case by case basis.

There are a lot of factors (assuming it's something that is really a fit or
near-fit in the first place):

\- the scope of the library in question (feature set can be both too small or
big, it depends on the situation if either of these things is a problem)

\- the maturity (age, testing in place, test _ability_ )

\- the subjective reputation/community factors can play a role

\- the amount of time you have vs. the costs of implementing (duh)

\- usually the licenses present a problem

\- the depth of understanding I want/need to obtain (an important point that
the article is touching on)

~~~
derefr
"Critical," to me, means "what your clients/customers are paying for," or
perhaps "what you're competing on with those in your product space."

Facebook's critical features are the friend network, the information page, and
the wall. Facebook would be stupid to write their own HTML rendering library.
They would be stupid _not to_ make sure they have the optimum data structures
and indexes underlying their relationship graph, and therefore probably
wouldn't use an off-the-shelf FOAF library.

~~~
timf
OK, maybe a better word is needed for that. How about "relevant."

------
bprater
My wheel may not fit your hub. While I agree that rebuilding systems is a bad
idea, it's also very difficult to get every square peg to fit in the square
holes we intend to put them in.

One of the bigger problems that could be solved now -- is coming up with a
system that gives programmers more insight or code when they are working on a
given problem. Until now, it's a crapshoot trying to find, say, a jQuery
module that does tooltips in the way I need them displayed.

------
sunkencity
Great article.

One of the main reasons I want to use as much library/finished code in my
production projects as possible is not just that it's faster to integrate a
finished code, but that there's an unknown X in for every new line of code you
write and that is how many weird bugs might come up, and how much time that
will cost to fix.

But then. OTOH, if you never try to reinvent the wheel you cannot judge
between wheels very good either.

------
psadauskas
To futher contort the analogy: You're not reinventing the wheel; you know its
supposed to be round an roll. Instead, you're changing all the internals to be
a better fit for what you need. Wagon wheels are different from bicycle
wheels, which are different from airplane wheels. All have a special set of
characteristics, but everyone that made one didn't invent the "wheel" from
scratch.

------
hibrian
I like reinventing the wheel. If someone makes a good wheel, it's not much fun
or educational to just say wheel.roll(); It's much more interesting to write
it and work through the issues. Guess it depends on the context, if you just
need a wheel to roll vs if you need to know how it works.

------
herval
Reinvent the wheel if you think you can improve the concept - but never just
for the sake of doing it...

~~~
bsaunder
You mean like airtrax? ;)

<http://www.youtube.com/watch?v=tPmC4KPvOfg>

I think people should be encouraged to reinvent wheels. Sometimes it's the
firm foundations of something that everyone takes for granted that need to be
questioned and reexamined.

------
kubrick
Exactly -- reinventing the wheel is perfectly sane if it means you don't have
to use a bicycle tire on a bus.

