November 22, 2014

Never Reinventing The Wheel Is Anticompetitive

Reality is that which, when you stop believing in it, doesn't go away.
― Philip K. Dick
Nowadays, you aren't supposed to write anything yourself. In the world of open-source software, you're supposed to find a library that does what you want, and if that doesn't work, commit a change that makes it work. Writing your own library is a bad thing because it's perceived as redundant if there's already a library that does most of what you want. The problem is that this is inherently anti-competitive. If there's only one library that does something, you have a monopoly, and then you get Heartbleed, because there's zero diversification. However, if I try to invent my own wheel, I'll just be scolded and told to contribute to an existing wheel instead, even if my wheel needs to have giant spikes on it.

I'm beginning to wonder if these people actually understand how software works. Code is not some kind of magical, amorphous blob that can just get better. It's a skyscraper, built on top of layers and layers of code, all sitting on top of a foundation that dictates the direction the code evolves in. If someone invents a better way to architect your program, you can't just swap pieces of it out anymore, because you are literally changing how the pieces fit together in order to improve the program. Now, I'm sure many coders would say that, if there's a better architecture, you should just rip the entire program apart and rebuild it the better way.

The problem is that there is no one-size fits all solution for a given task. Ever. This is true for any discipline, and it is still true in the magical world of programming no matter how loudly you shout "LALALALALALA" while plugging your ears. By definition you cannot create a software library that is constructed in two different ways, because that is literally two different software libraries. Thus, just like how we have many different wheels for different situations, it is perfectly fine to reinvent the wheel to better suit the problem you are tackling instead of trying to extend an existing library to do what you want, because otherwise you'll end up with a bloated piece of crap that still doesn't do what you want. If you actually believe that it is possible to write a vector math library that covers all possible use scenarios for every possible solution, then I invite you to put monster truck tires on your smartcar and tell me how well that works. We might as well ask the Flying Spaghetti Monster to solve our problems instead.

You want there to be several different libraries for rendering vector graphics. You want there to be many different programming languages. You want there to be multiple text layout engines. These things create competition, and as each codebase vies to be used by more and more people, each will start catering to a slightly different set of problems. This creates lots of different tools that programmers can use, so instead of having to use their Super Awesome Mega Swiss Army Knife 4000, they can just use a butter knife because that's all they goddamn need.

At this point, most coders will struggle to defend their position by falling back on the tried and true saying of "well, for most programmers, this is perfectly reasonable." Exactly what do they mean by most programmers? Because most programmers use C++, C, and Java, and are probably maintaining systems that are 20 years old and couldn't possibly apply anything they were just told in any realistic scenario. Do they just mean programmers who are making hip WebGL applications? What arbitrary subset of programmers are we talking about here? Of course, at this point, it doesn't matter, because they are literally cherry picking whatever programming community supports their opinion, and we're praying to the Flying Spaghetti Monster again.

Diversity is important. I am tired of programmers living in some fantasy world where all diversity has been eliminated and everyone follows the One True Path, and uses the One True Library for each individual task. This is not a world I want to live in, because my problems are not your problems, and even if your library is amazing at solving your problems, it probably won't solve mine. I'll go even further and say that this kind of thinking is dangerous. It reeks of cargo-cult coding and institutionalized knowledge designed to destroy creativity.

When people say you shouldn't re-invent the wheel, they mean you shouldn't re-invent the wheel if that's not what you're trying to do. If your main goal is to make a game, you shouldn't write a graphics engine. If your main goal is to make a webpage, you shouldn't write a webpage designer. However, if you just finished a game and think "Gee, that graphics engine was terrible, I'm going to make a better one," then writing your own graphics engine is perfectly fine.

Including the entire jQuery library just so you can have the $("id") shortcut is like driving a smartcar with spiked monster truck wheels down a freeway. It's dangerous, stupid, and completely unnecessary.


  1. Now I absolutely believe in connectivity between humans minds. I was going to write very similar thoughts (although yours are better converted to words), to criticize approach "don't waste your time on what is created" (when you see it's created awful), to criticize Brendan Eich for his "we don't need nothing except JS in browsers" narrow-minded approach.
    We REALLY need more tools, more foundations, more languages, more libraries and more companies working on the same things. And we shouldn't be inert to learn new things! Otherwise we will forever stuck with Facebook as a "main" social network, Google as a "main" search engine, and all evolution will be slowed down because of lack of competition.
    People waste tremendous amount of time to waste TV serials, and we are arguing about some time to reinvent the wheels? Make them flying already!

  2. Dogma in anything leads to mediocrity at best and, let's face it, there's plenty of mediocrity in the industry. On the other hand there are plenty of people developing exciting and new open source projects all the time. Some do brand new things and others compete with existing projects.

    For front end web-dev's there are quite a few competing frameworks and libraries to choose from.

    New programming languages like Rust are being developed. A time consuming and expensive undertaking with plenty of other perfectly fine languages that have been serving developers for a long time.

    I'd hope that your beef isn't with the leverage we all enjoy by participating in open source. Rather, I hope that it is with the uninformed and unimaginative who'd prefer to use a nail where a screw was needed because it was handy.

    1. You are missing the point entirely. Take your example with Rust and ask who dare to ask product owners 'switch to Rust' :)
      Take my example with JS and look how many languages on client-side we have now (TypeScript and similar - aren't 'final' languages).

      To be informed about a lot of bad tools is not a reason to not try implement better one.

  3. I too think divergence is inevitable. See what I just wrote:

  4. Very funny. I wrote about the exact opposite problem a few years ago where a student group would have their new webmaster tear down their entire site every year to rebuild from scratch. Back-end, front-end, databases, and all. Rebuilding the wheel every single time in the name of innovation.

    I think the point we can both agree on is there needs to be less if-then blanketing decisions and more thorough understanding of the situation. To mirror your example, if all you're trying to do is make the website look prettier, you don't need erase your entire content management system (and records too for that matter).

    1. The common thread I find in almost all of these things is that there is no one way to do everything. Every situation has to be taken on a case-to-case basis and you will never be able to prescribe a single best way to solve a problem. This is why it is critical to have lots of different perspectives on a problem.