Often I see on programming blogs someone say something akin to this statement: “I’ve written this library that does X.”
Almost invariably someone posts in the comments something along these lines: “you could have used Y for this, looks like another case of NIH.”
For those who don’t know, NIH is an acronym for Not Invented Here. NIH is a quick way of summing up an often corporate culture notion of rejecting anything not created in-house. There are plenty of reasons for adopting a NIH way of thinking (by no means is this exhaustive):
- efficiency: some solutions are just too slow to work
- licensing: I may not like the (GPL|CC|BSD|EULA) of an existing work
- technical incompatibilities e.g. you don’t want to make both the JVM and .NET frameworks a dependency on your project
- scratching the itch: one can derive satisfaction from figuring out a puzzle oneself
One thing that isn’t the same as NIH is Haven’t Heard of It. Being ignorant of an existing software solution is an extremely common occurrence. As an example, the Apache Jakarta Commons offers many wonderful extensions to Java that I’ve half-assedly reinvented myself before discovering its (in particular, its String utilities are great). CPAN had a vast amount of great information that is likely reinvented all the time. The ‘net is a wonderful means of disseminating information but just because there is a single blog post about a library doesn’t instantly mean that everyone in the world has no excuse not to use someone’s solution.
Hopefully in the future with tools such as Google code search and koders.com telling the world about a library that will solve someone’s problem. But it’s probably not a case of NIH that drove someone writes an 80% feature-complete clone of a library, it’s probably just ignorance.
Joel has a good defense of the NIH mindset.
Joel as usual tells an entertaining story with a good lesson. I think the case for “legal” embrace and extend can be applied here too. One of the best parts of my favorite license is that you can freely fork into your project and make it your own (rather like what Microsoft did with the TCP/IP stack in Windows NT). The BSD license is one of a few licenses that really benefit both commercial and open source software. Groups that say NIH due to special circumstances can do so with a blessing and adapt code as their own as they need it.
Unlike the GPL, I could create a company and write some software using a BSD library that I use as a starting-off point. It’s the best of both worlds: I can extend code as I need to and start that much faster.
BTW, the impetus for this post was a comment found on John Resig’s blog.
I’ve found it surprising just how difficult code reuse really is. Even when it’s code that I’ve written myself, and designed to be reused, it’s rarely simple. Every new project comes with special cases and reveals assumptions that I didn’t realize I was making. The more generalized a library becomes, the more complex it becomes internally.
When it comes to using other people’s libraries, first you have to actually find those libraries. Then you have to hope there is some usable documentation. You will often find that their way of thinking about the problem is different from yours, and that your project has a couple little quirks that makes their library an awkward fit.
I still love trying to reuse things whenever I can. I always hoped I’d get to the point where I had most things ready to go, and I could just sprinkle in a little from this library and a little from that, like making a soup.
Reuse works out best when you have a specific, well-defined task, and the library author has taken the time to build it right and document it well. See swiftmailer.org as a perfect example of this (it’s an SMTP mailer for PHP.)
I have really been benefiting from a practice that looks like the following: make something work (however you can), but the next project that comes along that is similar, make it as reusable as possible.
One of the nicest things about the Spring framework is its emphasis on object composition. Once you’re building little bits of code that you put together in a central place you free yourself up to making some truly useful and reusable code.
Another strategy is one of consistently and constantly re-assessing your needs in a project. If I write one bit using a totally home-grown package, perhaps the next bit can rework some of that.
I don’t know how many times I ended up making something that covered 80% of the functions of an MVC setup before actually using an MVC setup.