a companion discussion area for blog.codinghorror.com

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


#63

A huge community is busy re-inventing the wheel with GNU Linux, every UNIX utility was entirely re-written and in many cases re-specified differently.


#64

Standing on the shoulders of giants.

As a scientist, I know the humbling experience of thinking something up, looking for similar work in the literature, and finding stuff that far outstrips my simple thoughts. From 1973. I would say that the more complex the wheel you’re reinventing, the more likely it is that there is a better solution out there, that works in more cases, in parallel.

Hopefully if you reinvent a wheel, or at least reimplement one, you’ll see the size of the giants on whose shoulders you were standing. If they turn out to be small, great. If they turn out to be tall, be prepared to actually use the 3rd party version.

Here’s to the day you can just contact the guy who implemented this particular wheel before, and discuss the weaknesses and strengths of it.


#65

I hope people will read it correctly, particularly the learning part… :slight_smile: Ie. they won’t read it: Always to your own code!

There are several cases where one shouldn’t re-invent the wheel: the most obvious is lack of time. If my manager asks me to add PDF export to our Java application, and do so while meeting the deadline, obviously I won’t download the PDF specification and start coding the implementation: I just will hop to iText library (at best look at some alternatives) and learn how to use it.
While I would love to do the former, probably lot of fun, it isn’t realistic, we don’t have years ahead of us.

Now, in my free time, I will code my own algorithm of Delaunay triangulation, because it is fun and interesting and I will learn a lot in the process, and I have no deadline and bugs are mundane here.

If I want to do a DHTML animation effect in JavaScript, just for experimenting, I will try and code it in pure JS. If I must integrate it in a professional live page, I will use a JavaScript framework, because I know these people have spend thousands of hours making these work on (almost) all possible browsers, past, present and future (beta versions).

And as others point out, to re-invent the wheel, you have to have some capacity to do it right, at least if you must use it later… I wonder how many posts on StackOverflow ask: Is my regular expression of e-mail validation right?. Often, it is just No, even ignoring extreme/rare cases.

I remember your post where you state It is my work, I live out of it, I must code it myself and master all I do. It was about sanitizing input, if I recall correctly. I must agree here, and I suppose you did lot of research, looking how others did, what crackers uses to attack, etc.
Now, you are not a fool and use good ready-to-use products, like WMD and such. :smiley:


#66

Jeff -

Happily, Sturgeon’s Law characterizes all human endeavour. Ninety percent of what we do is crap. The trick is to figure out which ten percent to keep. Of course, ninety percent of that then becomes crap, by definition. So, don’t be surprised if ninety percent of the library you’re linking to is crap. In many cases your executable will only invoke a small portion of the crap library, but rest assured ninety percent of that will also be crap.
Of course, if the standard deviation is small, the best ten percent isn’t much better than the worst ten percent. In any case, if your customer is foolish enough to pay for it, re-invent away as long as they’ll give you a charge number. (Why does Firefox think endeavour is mis-spelled? Isn’t there a Space Shuttle known by that spelling?)

-Lepto


#67

We’re programmers because we love to solve problems; who cares if the problem has already been solved.


#68

I’m really glad you posted this, Jeff.

I have gotten the vibe from many of your posts that you advocate never writing your own code, choosing instead to mash as many libraries and frameworks together as possible and writing the minimum amount of code yourself.

I have always felt this approach to programming was wrong, and on some level, even… offensive? Not quite the word, but there was something about the vibe I got that was seriously off. That programmers should never do anything new because they’d save time if they just reused everyone else’s code.

Unfortunately, nothing new will ever get written under such an approach. Nothing existing will ever be improved upon or polished, either.

There’s definitely a time and a place for reusing code, or for purchasing components that can slot into your project to speed development time. Charting components are a good example of effective reuse - in most situations, the pre-built ones offer all the features you will need.

The reuse mantra easily goes too far, though. Sometimes, it really is better to write it yourself, if for no other reason than it eliminates a potentially crippling dependency. Relying on external companies for critical functionality in your system introduces unnecessary risk in ones business. Hopefully the bean counters won’t interfere too much in making these sorts of decisions.

So that’s why I’m glad you posted this - I think it presents a much more considered view of how programmers should think. I think it is very useful to create new wheels from time to time, and the ability to create wheels is a necessary condition to being considered a serious programmer.


#69

@Bobby, do you write your own jpeg decoding routines? Nah didn’t think so. Soapbox–


#70

I don’t know how people started flaming on Java/.NET with this post.
As Simon Boulton wrote, the key point is the last sentence:

So, no, you shouldn’t reinvent the wheel. Unless you plan on learning more about wheels, that is.

It’s about our own attitude as programmers. And it must be a conscious choice, each time:

  1. You understand that you are talking about a specific wheel
  2. You see which models are already out
  3. Do you want to improve yourself, by learning how to do this kind of wheel?

Of course, the answer to this question cannot be given, if you don’t create a context for it:

  • Are you doing it because other wheels only do 90% of what you need?
  • Are you doing it for fun or are you getting paid for it?
  • How long will it take to understand and reinvent?

If you are doing it as a real job then remember this: your customer doesn’t care about the wheel; he only cares about the car color.

  • Does it show on the UI? Then it’s always the most important thing in the universe
  • Is it a library? A protocol? A sort pattern? the customer simply DOES NOT CARE. It took you 1 week to do it? Good, next time he’ll give the work to someone else who does it in 1 day.

There is no simple answer to should I reinvent this wheel?. So, what’s the point of trolling on this?

As for me, my solution is: does the existing wheel cover 100% of what I need? Is it sufficiently used and tested? If yes, I use it, go home 1 hour earlier, and go play soccer :slight_smile:


#72

btw, is anyone else sick of people who throw around Moore’s Law any time they want to talk about any sort of quantity doubling over any sort of time period?

You are trying to sound smart and intellectual, but you in fact sound like a try-hard idiot. Stop it.


#73

All generalisations are bad :slight_smile:

In production: Pick which wheels work the way you want them too, or can be modified to do so more easily than re-inventing. Re-invent the rest.

When learning: Do whatever the hell you like, as long as it teaches you something. (Brainfuck, anyone?)

For leisure: Do whatever the hell you like, period.

It’s that simple. Next?


#74

Too many people don’t want to reinvent the wheel, but don’t have a wheel to start with.


#75

uh, just to clarify, my previous comment was not directed at Jeff, who in fact did not mention Moore’s Law at all. :slight_smile:


#76

I would agree the reinventing the wheel is a valuable educational exercise. But to do it continuously when there are better options wold indicate that you have no deadlines and or no lives.


#77

We dont reinvent the wheel, we implement wheels of sizes and materials that we need.


#78

Yes, it’s another one of those strange ‘memes’ that programmers seem to get stuck on. If you take a mostly good idea, and go completely off the top with it, to some extremely remote point-of-view, chances are it’s not such a good idea any more.

http://theprogrammersparadox.blogspot.com/2008/09/dependency-too-far.html

If you wrote it, it will be easier to deal with. The state of our industry is such, that just because the professionals wrote it, doesn’t intrinsically mean that is will be any better than you’re own solution (especially if you do your homework first).

Paul.


#79

Yeah, my problem is that reinventing wheels is FUN! I would much rather code a wiki engine from scratch than drop one in. But I have grown to realize that this isn’t always best for my customers. So a happy medium is to spike reinventing wheels, and only use it for production code if your spike can differentiate itself from other products and justify more time. More often than not, this helps understand why others’ wheels are built a certain way…


#80

Good post. I can now sell this at work! :slight_smile:

I’ve been saying for the longest time, that reinventing isn’t necessarily a waste. Atleast it helps you discover the right tool for the job. Even if you decide to throw away your wheel, you can ensure that the one you pick instead will suit your needs better and you can be 100% sure if you started with trying to re-invent it :slight_smile:

Btw, for all those who say that the projects that have tried re-inventing the wheel never went on time, here are some possible reasons why?

  1. If you get your scheduling/priorities wrong your project will be over-budget and not on time. It has nothing to do with re-inventing the wheel.

  2. Don’t try and re-invent something that isn’t absolutely necessary to re-invent. Well actually, try to re-invent but do it quickly, and drop it when you realize you are better off using an existing implementation.

For instance, I had to re-write hashmap implementation in Java once, since I needed synchronization but one that uses semaphores. In that case I had to implement it. For all other times, I stuck with the standard implementation.


#81

Richard Feynman always advocated reinventing the wheel.

What I cannot create, I do not understand. --Richard’s last words on his blackboard at the time of his death.

I find that people who stick with design patterns tend to never be able to think outside of their patterns (outside the box), and great creativity comes from being able to make the leap to a new way of thinking.


#82

My position has always been more of Re-invent the wheel if you need a better one. Wheels are generic in purpose, and sometimes you need a more specialized version. The wheels that go on nascar vehicles probably don’t belong on your skateboard, for instance.

Of course, the danger of that approach is that you start to think of anything you want to create as a specialization/customization of something that already exists- IE, the situations where you don’t really need a wheel in the first place.

We tried using the wheel lib, but our app kept rolling away!
That’s easy. We’ll just write our own Square Wheel.
Yeah, we’ll call it a ‘block’!


#84

@otherguy: Of course not… he’s too busy working on his OS.

@Lepto: Ha! That was my username for a brief period way back when :slight_smile: