When (not) to reinvent the wheel

Kevin Barnes wrote about Three reasons to reinvent the wheel a while ago. I responded in comments with an elaboration that I’ve written in some form or other many different times in many different places, and since that particular instance stands well on its own, I decided to post it here. Herewith, then, some thoughts on why you should not (always) reinvent the wheel.

By and large, as Kevin argues, reinventing the wheel is far from a bad idea. Not everything useful has already been written, and as we learn more and factors such as hardware capabilities and the ubiquity of the network change, previously ideal wheels will show inadequacies.

The problem in general is that wheel reinvention is done for the wrong reasons. Many people habitually reinvent dilettantish 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 while learning from experience is the most complete way to learn, it is also the slowest; it’s useful to help the process along if you can. But you’re not only free to do whatever you wish when it’s on your own time for your own personal growth, you are, in fact, encouraged.

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

In that case, 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 their 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. They will take months to implement a fast, well-featured templating system, and much longer for a moderately scalable, performant general-purpose relational database. The ultimate wheel reinvention, writing your own operating system, requires an exceptionally 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 matters is awareness. Sometimes you will choose to reinvent a wheel. Very often you will not. Both are equally important, and the choice depends on goals, needs and external constraints. There are no hard and fast rules; you need a thorough understanding of the craft to know one case from the other.