Reinventing the wheel

One of the most common mistakes I’ve encountered in development is trying to implement something that was implemented long ago. That’s called reinventing the wheel. There are lots of reasons to avoid doing it and perhaps one or two reasons to do it.

Why avoid reinventing the wheel

• Someone has probably implemented the wheel as open source, so why not use their work? If the implementation doesn’t quite meet our needs, we can very likely build on what already exists.
• Although we tend to think otherwise, we usually lack the experience and knowledge needed to implement the wheel.
• We’ll more than likely have to deal with problems we don’t know about when we make the decision.
• We’ll have to spend extra resources on implementation and testing. That means people and time, the most expensive items in the development cycle.
• We’ll probably force developers to switch to our proprietary implementation even though there’s a widely used de facto industry standard for the wheel.
• Tools that work with the wheel in one way or another probably exist already too.

Why go ahead with reinventing the wheel

• There’s no available implementation of the wheel, or even a piece we can build on.
• There’s a licensing problem with the existing implementation.

Weighing the pros and cons, I’d venture that in nine cases out of ten, reinvention is entirely unnecessary and is a mistake in terms of cost or side effects. It’s worth asking why developers are so fond of reinventing the wheel.

I see three main reasons:

• A need to prove to ourselves that we can do it
• Reluctance to spend time looking when we know best how to do it ourselves
• An inability to use ordinary sources of information: ask a colleague, then Google, and finally a professional mailing list

At least the first two reasons are, how shall I put it, pretty stupid …