Reinventing the Wheel

An all too common phrase in programming is “Don’t reinvent the wheel”. However, I believe that the phrase is often used incorrectly.

First, ‘the wheel’ is a theoretical concept. It is the notion that if something is ‘round’, it will ‘roll’, and you can put that under other stuff in order to move it forward. A bike tire or car tire are wheels, but creating a new type of tire is not ‘reinventing the wheel’; it is actually just reimplementing one. You haven’t reinvented it unless you replace ‘round’ with something else, like a hexagon or tank track.

In software, that means that if you write your own persistence solution so that you can avoid using an RDBMS, you have not reinvented persistence; you just went your own way for the implementation.

On the web, we do occasionally see really neat alternatives for ‘wheels’. Mostly, though our vehicles and furniture stick with the familiar old round things that have been around for millennia.

The reason is simple. The concept of a wheel works really well. It is state-of-the-art for moving things. In a specific case, you may need to implement your own variation of it; maybe air in a rubber layer is inappropriate, but rarely do you need to revisit the theory. It is fine.

It is also good that other people are exploring alternatives, as some of them seem quite useful, but if you are asked to engineer something that moves right now, the theory of a wheel is probably the best place to start. Then, maybe, you can leverage an existing implementation like a castor to get yourself going.

All of this is the same for software. You are asked to put together a big system or product, so you break it down into small parts. If one of those parts is ‘persistence’, you first look at an RDBMS or NoSQL. You evaluate the properties of both and likely choose an implementation that honestly best fits your requirements.

You would not commit to doing your own implementation unless there is a particularly nasty requirement that is absolutely not met by any of the existing implementations.

But if you did decide to go your own way, first you would acquire the full knowledge of all of the theories, the state-of-the-art for persistence. You’d know it all, from the distributed fault tolerance perspectives all of the way over to data normalization.

You can’t skip parts because you’d have to reinvent them, and since most of them are decades old, you’d be falling right back to ground zero. You don’t want some piece to be crude if there is already an implementation out there that is not crude.

Given the requirement to know the state of the art, it is pretty much not an option for most people to write their own persistent solution. They don’t have the knowledge to get their implementation up to the state-of-the-art, and going far lower isn’t going to net them the benefits that they need. This is the core of “don’t reinvent the wheel”, which is that you shouldn’t, unless you really can. And you really can when you know a crazy amount of stuff and also have a crazy amount of time to get it implemented; both are rare circumstances. So, don't do it.

But while persistence is a very deep and broad knowledge base, people frequently make the mistake of applying that logic to much simpler issues.

You could, for instance, reinvent or reimplement your own widget. Reinvention is trickier as the widget will be perceived as eclectic for most users, so they probably won’t like it, but there are times when a brand new type of widget is actually what is needed. Rare, but possible. As for reimplementing, if you fix enough of the annoyances with most modern widget sets in order to lift up their quality, then it is probably very worthwhile. Or maybe you just wrap all of the other widgets to fix their inconsistencies, another variation on reimplementation that often makes sense.

This applies to all sorts of places in the tech stacks where the current implementations are weak or just glue over something else. You probably don’t need to reinvent them, but it may make your life considerably more comfortable to reimplement them, or at least wrap them up nicely. These two types of coding tasks are really good but, unfortunately, are often confused with reinvention. You’re not reinventing the wheel; you are just applying your knowledge to get a better implementation somehow. Of course, to do this successfully, you need that knowledge first. Without that, you are just going backward.