Inventing a Better Wheel

As programmers, there are two types of problems we solve: those that have been solved before and those that haven’t.

Generally it makes business sense to concentrate on what we’re primarily selling and not get distracted by non-core functions. From a programmer’s perspective, that means we should avoid reinventing the wheel – we should use existing libraries and services where possible, then spend our quality time on code that makes our product new and unique.

But at what point should we not bother checking whether something has been coded before?

Did we really sign up as programmers so that all we’d be doing is trawling the web, evaluating libraries, copying and pasting boilerplate code, then logging bug reports with other developers when things break? Are there ever business cases for saying “Screw it, I’m going to just write this myself, because I can do it quickly and it will work exactly how I want it to”?

The fact is that if you search hard enough, you can find code of varying quality for just about everything. No? Are you sure you tried searching in Japanese? What about 80’s usenet groups? Where should one draw the line?

I think reinventing the wheel is a pretty awful analogy for a software anti-pattern. It implies that the original solution can never be improved upon. That is nonsense. The so-called wheel can become obsolete overnight, or its owners could stop maintaining it. The wheel has a different value at each system where it’s used. It’s entirely possible to invent a better wheel.

As a rule of thumb, if I estimate that I can create a library that I’ll be using a lot in 2-3 days, I’ll probably code it myself. Here are some reasons:

  1. I’ll know my code. I don’t have to spend time adapting to someone else’s naming conventions and way of thinking.
  2. No scouring of badly written FAQs or knowledge bases. No posting on Q&A sites about obscure problems. Certainly none of my pet peeve of working with open source frameworks: “This documentation is under construction.”
  3. My code is tailored to my system. My interface is not bloated with things I’ll never use, and its performance will not suffer due to it trying to be a one-size-fits all solution.
  4. Most importantly, I won’t have to take responsibility for someone else’s bug. Think of it this way: which of these is better to tell a customer? –
    1. “Our website broke. It was someone else’s fault, and we’ve logged a bug with them. There is nothing we can do about it except wait. We’ll keep you updated.”
    2. “Our website broke, and we were able to fix it immediately.”

Just so we’re clear: I am a big advocate of using tried & trusted frameworks and API’s when possible. But sometimes what is out there doesn’t cut it for everyone’s needs, and I don’t believe we should necessarily discourage ourselves from building our own version.


About Andrew

A South African living in New York City, working as a software architect in the food industry.
This entry was posted in development and tagged , . Bookmark the permalink.

One Response to Inventing a Better Wheel

  1. I constantly spent my half an hour to read this blog’s articles or reviews everyday along with a mug of coffee.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s