Don’t reinvent the wheel unless you’re one of the 0.05% of people smart enough to get it right.
EXACTLY. Chances are, you are not one of those people. You are not Charles Moore. Charles Moore did not have Visual Studio, .NET and a ton of hardware horsepower.
Who cares? Most code doesn’t need to scale, and when it does, you can always change it then.
lol
Arguments agains reinventing the wheel:
You are not the brightest bulb in the pack, otherwise your job would be inventing wheels, but instead, you write database front ends
in ASP for a small retail bank, so don’t do it.
Even if you were the brightest, you probably do not have enough experience to invent wheels, so don’t do it.
Even if you are the brightest and have experience, the truth is, the already-invented-wheels are good enough for 99% of programming tasks, and you would be just wasting everybody’s time inventing obscure 1% wheels.
I think it’s safe to say that if you are re-using someone else’s wheel, you should expect to have to tune it up before it works for you. In that process you might decide to write it yourself or refactor it enough that it hardly looks like what you started with.
I think what Jeff and the SO devs went through with their editor control is a good example of this.
EXACTLY. Chances are, you are not one of those people. You are not Charles Moore.
And you never will be with that attitude.
There’s another reason to write your own wheels: maintenance and comprehension.
If I use somebody else’s library/module and they change it, I might have to rewrite MY code. If I use someone else’s module and something goes wrong, I have to debug code that I didn’t write and that’s usually much harder than figuring out what I might have screwed up.
Yes, you can take that idea too far. But I think most people don’t take it far enough. In general, I’d rather have code I wrote - even if the other guy obviously did it better (which is usually true).
More than half the time the wheel is reinvented because of developer ego and not because there is a deficiency, realistic risk in using the third party library, or willingness to learn. And in my professional experience I have found that the bigger the ego the crappier the code. just because your code is complicated does not mean that you are an artiste.
Good posting Jeff, and I think this speaks to a broader idea in software development: we should always question the rules and basic assumptions that permeate the industry. I don’t mean to say we should always break those rules, or ignore the assumption, just question them. Just because Granddad did it and it worked for him doesn’t mean I should. Indeed, I propose that the more ingrained or accepted an idea or technique is, the more suspect it becomes. As some famous activist once said: Progress comes one funeral at a time.
Reinventing the wheel is fun for the developer and good for him (he gets to learn how to make the wheel, etc.)
But for the customer, 99% of the time, the original wheel is good enough and all you are doing is wasting their money/time.
Please - from a client of many software projects, build me something that works in the quickest time possible! Don’t reinvent unless it is a critical success factor FOR THE CUSTOMER!
There might also be a parallel with optimization here. Unless you exactly know that you’ll need a new kind of wheel and how it has to look like, you’ll quite certainly be better of starting with an existing wheel. And when your program runs, then you may consider the alternatives - and one might be to reinvent the wheel you started with.
On the other hand, I can’t help thinking that the reinvention of the wheel is one of the major problems of our industry. It’s hard for me to imagine how the electronic industry would have reached anything if every electronic engineer had wanted to reinvent the transistor before building a new TV or amplifier. But that’s a complex issue that would require quite many blog entries to discuss event superficially.
And never forget that the tendency to reinvent the wheel often comes from the not invented here syndrome, or the fact that It’s harder to read code than to write it (Joel on Software) or not so seldom from the plain ignorance that wheels already exist etc.
My final two cents: don’t take the advice not to reinvent literally (as Jeff said), but never think you’re so smart that you don’t need to learn from the existing wheels and wheels makers - as this would be a sign of abysmal stupidity…
That was really strange seeing the title of the article this morning because I just wrote about the same topic a couple of days ago. The problem with the advice of not to reinvent the wheel, is that it is over used and does not recognize the fact that in many situations, it is better to redo something yourself.
Meh, some wheels are easier to reinvent than to research.
Often I go to the web to find something to use premade and end up taking more time googling and RTFMing than I take just writing the code myself.
Programming is easy - spending all day reading useless docs or searching the web is the real waste of time.
There are several problems with reinventing the wheel:
It means your implementation is completely different from other implementations. When it comes time to support your code, the people who have that arduous task will now have to figure out how your wheel works.
Your implementation will probably stink. If you are talking about Open Source libraries, they have been honed by hundreds of users over time and architected by people who are experts in their fields.
You could be spending your time elsewhere. If I decide to rewrite some basic modules, I am not concentrating on the parts of my application where I should. I’ve seen too many projects where weeks have been spent on reinventing the wheel because someone thought they could do it better when they should instead be concentrating on their application and how it works.
This is not to discourage people from exploring and poking. One of my major complaints is how little most developers understand what they are doing. Too many language implemented features, frameworks, and other things designed to make our life easier means we no longer understand how basic stuff works. How many developers can explain the difference between a bin sort, a shell sort, and a bubble sort?
However, before reinventing the wheel, why not poke around the current wheel and see how it works? This is easy to do with Open Source projects. Sign up on the developer’s list and download the code. Ask questions. Learn what is involved. Munge the code a bit. Submit improvements. Then, once you understand the basics of this implementation, and you think you can do better, start your own open source project, and provide a bit of competition.
I sympathize with your argument. Right now I’m sitting in my cave, writing permission-related code in ruby on rails. The very idea of using a plugin for this part of the application made me feel very uneasy. I just wanna know everything about it - in detail.
However, throughout my career I did encounter some grossly reinvented flat tires that I don’t want to go unmentioned:
A Webserver written in Java. Using jetty would just have been too boring, I suppose. Oh, and it couldn’t do HTTP1.1
An ex-colleague decided to spend days to write some nifty encryption algorithms that were supposed to prevent crackers from pirating the software. What do you think… did he succeed? 
Months were invested in developing a form layouter, written in Cocoa. I was the guy who was supposed to maintain that code after the offender took off. After discovering that it rewarded resizing the window with a segfault I spent the better half of a Tuesday morning replacing the functionality with WebKit. Amazing how these browser components do form layouting these days! Scriptable.
So before reinventing the wheel, please ask yourself the following questions:
I tend to reinvent the wheel all the time. It really does give you useful insight and experience. It lets you branch out and work on things outside of the wheel afterwards in a more useful way.
Hi Jeff,
Interestingly, the evidence supporting your point is brought forth by two people who are some of the best coders in their field. There is no doubt that whatever wheel they come up with is very likely to be at least as good, if not better, than what existed before.
I sympathize with the idea of reinventing a wheel with the intention of learning more about wheels, but unless you are one of these exceptional programmers, once you’re done, you and your team will be better off discarding your work entirely and use the more established version.
–
Cedric
(who works with Bob, and yes, he’s an amazing Java coder)
Sometimes it is pointless. The existing solution works and works well and it saves time to revinvent the wheels that may exist but do not work well at all.
I fully endorse doing something over, but only if you have the time to learn or the need for something better than what already exists.
All too often, we don’t have the time and it’s often considered quicker and faster to either live within the pre-existing limits or even live with its flaws.
If you ever wondered why so much code is crap, it is because it is filled with compromises - workarounds for things that fall short and patches for things that are just plain broken all to meet timelines and budgets.
I have read the maxim ‘don’t reinvent the wheel’ so many times, but I’m a mathematician, not a programmer - so the programming I do is about enjoying a hobby! To me it’s all about ‘reinventing the wheel’; both to learn more about wheels, but also to learn about programming.
I’m glad to finally see a caveat about ‘reinventing the wheel in order to learn more about wheels’ (and I would add, ‘to learn more about the tools one uses to make wheels’).
ex animo-
I agree with David W.'s comment: Your implementation will probably stink. Look at http://thedailywtf.com - many of the posts are developers who reinvented wheels (often those provided by standard libraries) and did so poorly. Is the reinvention thread-safe? Is it secure? Does it scale? Did you write tests? Has the code been reviewed? Is it reusable?
I’ve certainly encountered buggy and ill-fitting third-party libraries. One size does not fit all. But that seldom justifies redeveloping the feature set on a project. Often another library will be a better fit.
Many code smells and design principles can be boiled down to Don’t Repeat Yourself. Remove duplication when you find it. Reinventing the wheel is the ultimate violation of the DRY principle.
Everybody loves reinventing wheels.
Lots of people here are geniuses; just ask them.
And are so much smarter than everyone else. I might not be smart, but I sure am used to being on change control boards.
Here is an engineering decision making algorithm. It’s not mine: just common in engineering professions.
Are you going to SELL the (X) ?
Is (X) part of your core business ?
Because we do software, we have the option of
Can you find an open source (X) that does the job ?
If its open source, you never need to upgrade just because the vendor tells you to.
Use an open source library that is good enough. ( remember, worse is better)
If there isn’t one, write the code. Budget to have to maintain it forever. After all, it’s unique. But that’s okay, because you’re a genius.
This algorithm does suggest never using anything that isn’t open source. Not bias, it is merely an exercise in engineering configuration management. Can you spell engineering configuration management ? Our next phrase will be professional liability. A sentence using that word: Aren’t we lucky that software developers have no professional indemnity.
If the customer is not interested in long term support ( less than a couple of years or so) then grab whatever vendor provided crud you can, take their money.
(Then in two years take it again.)
Learn by doing. Try doing engineering. Coding is scratching an itch. Don’t scratch yourself in public.
I guess it’s all a question of attitude. If you attempt to reinvent the wheel for learning and improvement, after knowing what’s out there and without any tight schedule, great.
But don’t do it out of lazyness to understand the existing solutions or on projects with serious time-constraints.
Also, don’t try to reinvent everything at once.