Has someone ever told you "Don't re-invent the wheel"?
Again and again I read somewhere around the net that 're-inventing the wheel' is one of the worse errors a programmer can fall into. In fact, I've read it so often that the only thought of doing it makes me re-think over and over other ways of solving (or ignoring) the problem.
But here, I advocate my pro's (the cons can be found elsewhere) for re-inventing the wheel, or at least not being frightened of it. You can also read the follow-up: 8 reader reasons for re-inventing the wheel as a programmer.
1. I don't like the default wheel color: Sometimes you need a specific type of algorithm, one that the 'library standard' just does, without the bells and whistles you need. Writing your own version allows you to tweak it to suit your problem domain. Do it!
2. I want a bigger wheel: What happens when the usual algorithm doesn't fit at all? When you need to write really context-specific code, working with generalistic libraries is impossible. Even worse, what happens when you are writing the specific library? Go ahead!
3. I am a wheel engineer: if you are deep in the know-hows of the subject, re-inventing the wheel is a way to be sure of your complete knowledge of your domain of expertise. A kind of self-knowledge test. Test it!
4. I want to know how does the wheel work: related to the previous item, but focused to amateurs on the subject. I feel this way quite often, and sometimes this has paid off in the long run. This can lead to spicing up a boring afternoon. Discover it!
5. My wheel is better than your wheel: Pride. You can write it better, can't you? Closely related to the programmer virtues: laziness, impatience and hubris.(check this page for them). Be proud of it!
6. Proprietary vs free: maybe the wheel you want to use is a proprietary wheel, thus you can't add it to your open-source project, or have to pay some fee to use it. Free it!
7. Create a new wheel: you need to know how the old stuff works to be able to create the new big thing (usually, in most areas). We are standing on the shoulders of giants, but if we don't know how tall they are, we can step over midgets. Learn it!
8. Boredom: maybe you have a free Sunday afternoon and don't want to code something over-the-top, and you decide to write your own algorithm for X. Closely related to reasons 4 and 5. Enjoy!
Do you have your reasons and they are not in this list? Post a comment and I'll write a new (collaborative) version! (Written! 8 reader reasons for re-inventing the wheel as a programmer).
But here, I advocate my pro's (the cons can be found elsewhere) for re-inventing the wheel, or at least not being frightened of it. You can also read the follow-up: 8 reader reasons for re-inventing the wheel as a programmer.
1. I don't like the default wheel color: Sometimes you need a specific type of algorithm, one that the 'library standard' just does, without the bells and whistles you need. Writing your own version allows you to tweak it to suit your problem domain. Do it!
2. I want a bigger wheel: What happens when the usual algorithm doesn't fit at all? When you need to write really context-specific code, working with generalistic libraries is impossible. Even worse, what happens when you are writing the specific library? Go ahead!
3. I am a wheel engineer: if you are deep in the know-hows of the subject, re-inventing the wheel is a way to be sure of your complete knowledge of your domain of expertise. A kind of self-knowledge test. Test it!
4. I want to know how does the wheel work: related to the previous item, but focused to amateurs on the subject. I feel this way quite often, and sometimes this has paid off in the long run. This can lead to spicing up a boring afternoon. Discover it!
5. My wheel is better than your wheel: Pride. You can write it better, can't you? Closely related to the programmer virtues: laziness, impatience and hubris.(check this page for them). Be proud of it!
6. Proprietary vs free: maybe the wheel you want to use is a proprietary wheel, thus you can't add it to your open-source project, or have to pay some fee to use it. Free it!
7. Create a new wheel: you need to know how the old stuff works to be able to create the new big thing (usually, in most areas). We are standing on the shoulders of giants, but if we don't know how tall they are, we can step over midgets. Learn it!
8. Boredom: maybe you have a free Sunday afternoon and don't want to code something over-the-top, and you decide to write your own algorithm for X. Closely related to reasons 4 and 5. Enjoy!
Do you have your reasons and they are not in this list? Post a comment and I'll write a new (collaborative) version! (Written! 8 reader reasons for re-inventing the wheel as a programmer).
If you enjoyed this post, please share it with your friends or subscribe to this blog!
Related posts:
19 Awesome Comments. Add Yours!:
9. Quality: All software contains bugs. If you need to rely on a piece of code, it is better to write and understand it yourself than to trust a random library you've found somewhere for download.
@Luzius Messier,
I'm sorry but statistically that is absolutely, positively wrong. If you studied anything about software, software engineering and software in the wild you'd know that often the stuff that is released is the stuff that is tested, field tested, and it works. The stuff you right will have to go through the same quality steps to ensure it is of equivalent quality. It is safer to rely on something tested and mature than to go and hack at it only to relearn the mistakes of the past. This is of course requires that you agree you're being pragmatic. The random library is often way better use of your time than if you do it from scratch and there is work from Reid Holmes at UWash which suggests so.
> statistically that is absolutely, positively wrong
Oh, come on - you can't seriously post a statement like that to a maths-based blog and then not actually provide any statistics!
I hope you refer to Done-and-gone's comment :) I didn't give any statistical reasoning (I don't feel I need to, I just give reasons), and Luzius did the same.
Btw. I quite like Luzius reason, and will definitely move it above being the 9th reason, I think it deserves to be at least in the 6th position :)
(Not to mention that your use of the word "often" would appear to rule out the "always" implied by "absolutely, positively wrong".)
Now, counter-arguments. Here's a key reason why something I write might be more reliable than the most field-tested library I can find: The field library will be written as generally as possible. It will likely incorporate code from many contributors. There will probably be a vast number of potential code paths, and the likelihood of any of them being comprehensively explored is vanishingly small. Whereas the code I write will be exactly customised for the situation for which I need it, meaning it will be short, single-purpose, and crucially only contain a single execution path.
It might well end up being more efficient, too. If you load a function from a dynamic library, or even a static library, it has to stay general; the compiler's work with that function is long done. Whereas a short customised function included as source may well disappear into inline code - indeed, even if it contains a number of code paths, the optimiser may well be able to flatten it out into straight-line code because of constant factors. And there won't be any penalty for having to page in 4k of code just to execute the 200-byte function stranded in the middle of it, either (not to mention not polluting your BTB cache or bubbling your pipeline... P4s haven't gone away, you know).
I firmly believe that someday, especially after massive parallelism becomes ubiquitous, the computing industry will look back on dynamic libraries and realise that they were the worst possible solution to something that rapidly became a non-problem. ...OK, I don't believe that. But I am wholly convinced that they should.
Sorry - yes, in both instances I am replying to done-and-gone.
Creating wheels is fun. Might not be profitable. But fun nonetheleess.
10. I want a faster wheel: Sure there are nice wheels out there already, but they are rarely optimized to your exact needs. Sometimes I need to build a lightweight wheel without the spinners and light-up stem caps. It can make my code execute faster than someone who buys from Big O, and there are times when this is worth the effort.
Thanks for writing this. Yes, there are perfectly solid arguments for not reinventing the wheel, and they should be considered. But just as with, ahem, "Design Patterns", they should only be applied when applicable.
The reason you give as "to understand how the wheel works" is my favorite. Sure, I aced complexity analysis in algorithms class, no problem! But getting down and dirty with my own container class that has methods for bubble sort, heap sort, quick sort, etc., was a beautiful way to concretize what I had learned.
Thanks for posting this.
Couple of other excuses for engaging in the fun activity of wheel reinvention:
a) After I've re-invented it I will really know just how the wheel works - you get to understand something better by implementing it yourself than by using someone else's code.
b) There are lots of wheels around, but I have a funny shaped axle. It's quicker to re-invent my own wheel because then I can be sure it just fits where I want it to go, whereas otherwise I'd have to spend hours inventing an axle adapter. Using off-the-shelf implementations sometimes demands coping with a lot of baggage in the way of interfaces and setup, that may not be a good fit with code you've already produced. Sometimes it's faster or better to just implement something yourself because it will then slot neatly into your existing body of code.
To clarify I wasn't referring to "All software contains bugs", I was referring to what Luzius said, "If you need to rely on a piece of code, it is better to write and understand it yourself than to trust a random library you've found somewhere for download."
Maybe I stated it too strongly for you folks but the fact remains that most models of software development either suggest that writing library quality software is expensive, or to write safe mature software is expensive (hell all the COCOMO models suggests writing anything new is expensive). Mr. Meisser is suggesting that your mere rewrite will be better quality than something off the shelf, and he specified libraries too.
If you want to rewrite, understand the context and understand that the undertaking it could cost you a lot of time and effort, especially if you want to achieve the maturity and quality of much of the code out there.
The blog post is about is about reasons, you would do well to understand the costs of doing so.
Yet as always it depends on the context. I suspect Mr. Meisser was thinking of short bits of code, not larger chunks like encoding conversion, XML libraries (ugh), crypto libraries (Debian showed that even modifying crypto libs was fraught with peril), etc.
I enjoyed reading this. I'm not a programmer at all, so when I have to do work on the Wordpress code to get my site to do something new, the closest analogy would be "staring at a warehouse full of parts and wishing some of them would just start rolling already".
I think you missed one:
You didn't know that it was a wheel, at that it already was invented. Happend at least thrice to me so far.
Good grief.
See, this is the kind of thing that leads to folks writing their own version of htonl() "because I can". While under deadline. And in the weeds.
You want to make your own wheel, that's cool; but for crying out loud, exercise some judgement before you even start!
@Steve Bush: I'm glad to read. Hope you can come up with something about your WP!
@Jerboa: Good ones, too :)
@Jens: LOL, really.
@Sparks: yeah, better to think *before* doing it ;)
The worst mistake I've seen devs/teams make over and over again is to take on a huge dependency for solving a very tactical and scoped problem. But the large wheel will solve that small problem and so much more. Everything looks like a nail when you have a hammer.
The problem is you can typically solve that tactical problem with a small piece of targeted code - often in less time than you spend solving that first road block hitting that first cryptic issue with the large wheel that you've taken on.
It also typically leads to more fragile solutions built with many more complex moving parts, with larger footprints, varying release cycles from all the dependencies etc...
Lastly, all of the solutions you tack together often bound your imagination with coming up with what should be ideal solution. Instead, you bound your imagination by what your hobbled pieces are capable of.
Instead, you should start out, define the ideal experience, write what you need and take on smart dependencies that you *have* to take on. The last part is of course the tricky balance that everyone struggles with. I personally view it as needing to take on a dependency instead of wanting to. I think many devs want to play with many technologies and take on more than they should.
Add this reason, please:
In making the wheel--the wheel makes you. I served a toolmaker apprenticeship and early on we were set to the tasks of making our own tools, v-blocks, angle plates, dividers, etc. Sure we could buy them, but they wanted us to become _toolmakers_. Making wheels refines your ability to make wheels. To this day I have and use tools that I labored over as an apprentice. And a good feeling it is to see the dates stamped in them of 1977, etc. from when I made them.
As a small counter argument...
So, having written your own version of a library function, are you prepared to support it for ever, or would the next developer come along, fail to understand your code and rewrite it. Repeat the last phrase forever!!!
Good counter argument. Of course, my idea of re-inventing the wheel is more focused on personal projects. On a real developer case, for a big firm... It may pay off doing it in some cases, but then some policies should be applied (good commenting, maintainability, good design...) to let it survive the developer being fired or moved to management, or such cases.
Ruben
Post a Comment