“Not Invented Here” SyndromePosted: October 9, 2009
I responded yesterday to a post by Steve Smith about programming anti-patterns. After writing a brief note about “Not Invented Here” syndrome, I thought about it some more and decided to expand on my comment.
Not Invented Here (NIH) happens for a variety of reasons. Those that follow NIH are loath to incorporate any ideas from outside their own team (and sometimes their own heads.) It’s a sort of mental ossification that occurs when a developer is unable to value contributions from outside. This may manifest as a reluctance to incorporate open source code into a project. NIH adherents tend to distrust frameworks developed by other companies or developers. At its worst, NIH folks won’t even accept contributions from other team members.
“If it wasn’t Invented Here, by me or my peeps, we won’t use it.”
It is understandable why developers might prefer their own code and methods over those written by another. Codebase familiarity is comfortable and fast. New methods take time to learn and really incorporate, and we don’t always have the time or management blessings to climb new learning curves on the company nickel. We rarely get paid extra to write good, reliable software (there’s a whole other can of worms!)
It’s important to fight the urge to stick to your comfort zone. As developers, our value comes not from what we know, but what we can learn and how quickly we incorporate new information. Imagine trying to write an entire application without an Internet connection. The most competent developers still need to research and look up syntax now and again. It’s important to go beyond simple task-focused research. Challenge yourself to the core! Ask tough questions about why you do things the way you do them. Try new things. You can’t expect to maintain good professional bona fides while working in a bubble. New ideas are essential to any developer’s continuing education.
Avoiding NIH will also help you avoid RTW: Reinventing the Wheel. If you decide to build the biggest baddest new blogging system (for example), first ask yourself why you think yours will be better than the other million open source blogging systems out there. If you have a good answer, go for it! However, even if you think you have a totally new concept filled with win, do yourself a favor and evaluate the other systems. You’ll learn a TON.
There is a caveat here: don’t go looking for nails every time you find a shiny new hammer. Tools are just that: tools. You can build something great or smash your (or your clients!) thumb. Evaluate each newfangled thingie, whether it’s TDD, IoC Containers, Mocking, frameworks, or whatever, with a critical eye. Take some time to try it out. With a little practice, the really compelling stuff will feel like an old shoe that you’ve worn for years. Let the stuff that doesn’t sing for you just fall away. It’s extra effort, but it’s totally worth it.