There’s no size limit to the “Not Invented Here” Syndrome.

The “Not Invented Here” Syndrome is when people rewrite software that already exists and is ready to be reused. In general, it’s better to reuse software instead of rewrite it yourself. There’s a multitude of reasons:

  1. Rewriting something that already exists is a time sink. That time could be better spent writing some code that doesn’t already exist.
  2. You probably aren’t the first person to find the existing code. More eyes on the shared code mean it’s probably higher quality than what you would come up with at first. That’s because its been tested by the people that used it before you. It probably has features in it that you didn’t even realize you wanted.
  3. Its been vetted by other people. That likely means bugs have been found and fixed in it. If you write the code yourself you may end up introducing bugs that have already been fixed in the library.

Most developers realize all these problems at some point in their career. There are actually some benefits to reinventing some code though:

  1. You get to learn in-depth how something exists that would have been a fuzzy abstraction to you.
  2. You have complete control over the end result and can immediately fix any bug you discover. Of course, if the reusable code is open source, you can already do this on the reused library so it’s not a very strong point.

But the pros and cons are not really what I wanted to talk about in this article. I wanted to talk about this other problem that I see in the programming community. It’s the idea that if something is easy to do, it should be reinvented. I hear things like, “People are importing libraries to do something that I could write in 10 lines of code”. They say this as if it’s a bad thing. They think, why would you want to include a dependency when you could just write that code in 1 minute?

I completely disagree with this mentality. If you’re rewriting 10 lines of code that you could import as a library, you’re Reinventing the Wheel and you’re getting all the downsides that I mentioned above.

I’ve heard excuses like, “The library is 500k and I only need 15 lines of it”. That might be a good excuse if adding an extra 500k to your project had a noticeable, negative consequence. But that’s a relative drop in the bucket for most of the projects we all work on. It’s not a good enough excuse to potentially introduce bugs and waste time.

A related excuse I’ve heard is that the library does 20 things and I only need 1-2 of them. I have never been negatively effected by that. I just don’t use the other 18-19 things the library can do and they don’t interfere with the rest of my code.

There’s no size limit to the “Not Invented Here” Syndrome.

Join the email list for bonus content.

One thought on “There’s no size limit to the “Not Invented Here” Syndrome.

  1. Will Rubin says:

    Ridiculous. One reason to write it yourself is to try out a new idea that’s not included in the other. Especially if that change to the existing code would involve more time digging auound the code to understand it. It’s often easier to just code it yourself in your own style.

    Another reason is fame, fortune, and ownership. If you code it yourself you own it and can distribute it under your own terms. And if it does become popular you get a big resume boost.

    Lots more reasons you don’t cover but on phone so typing sucks.

Leave a Reply to Will Rubin Cancel reply

Your email address will not be published. Required fields are marked *